What I documented is correct, but incomplete. To be totally complete, I should have said
* COPY BITS 0-31 OF R13 INTO BITS 32-63 OF R0 AND * COPY BITS 32-63 OR R13 INTO BITS 0-31 OF R0. But, in this code, I did not care what happened to bits 0-31 of R13 or anything in R0. I could not do the simple LR R0,R13 because I use the lower fullword of R0 later in the code. I have a liking for MVCL R0,R14 to copy variable length strings. This despite the apparent fact that, in most cases, an MVC loop and an EX of an MVC for the last < 256 bytes is more CPU efficient for small moves. And, in the code in this particular routine, most moves are likely to be less than 256 bytes. It is a POS (not Point Of Sale) blank compress/decompress routine which uses a weird RLE encoding that the original person thought was "clever". I guess the documentation was incomplete since I did not explain why I needed to use the high word of R0 for storing the low word of R13. I will fix that. On Wed, 26 Jun 2013 08:49:36 -0500, John McKown <[email protected]> wrote: >* COPY BITS 32 THROUGH 63 OF GENERAL REGISTER 13 INTO >* BITS 0 THROUGH 31 OF GENERAL REGISTER 0. THIS SAVES >* THE AMODE(31) SAVE AREA ADDRESS FOR LATER. > >But I don't really like it. May as write COBOL code <grin/>. So I was >thinking that I could use a type of subscript notation. E.g. > >* COPY R13[32..63] INTO R0[0..31], >* SAVING THE AMODE(31) SAVE AREA ADDRESS FOR LATER. > >Does that "look good" to others? I.e. would a regular HLASM programmer >intuitively understand it? > >Oh, the above was the comment in front of: > > RLLG R0,R13,32 > >Granted the comment was not 100% technically correct. Either I misunderstand how that instruction works, or I would say that comment is in fact quite misleading. As I read the comment, you're saying that you affected only bits 0..31 of R0, and left bits 32..63 alone. But in fact you replaced all of R0 if I understand the way the RLLG instruction works. You ended up with with a complete copy of R13 in R0, but with the upper- and lower-half interchanged. And at that point, why not just use LR R0,R13 instead, with the equally simple way of restoring the original value being LR R13,R0? -- Walt
