True, and it is undoubtedly faster to use SR R15,R15 than it is to use LA R15,0 to zero the register - there are no storage fetches and real subtraction is not needed if the result can be predicted, as it can in this case. However, the discussion had more to do with fetches of boundary-aligned vs. non-aligned data. There was no mention of the optimum speed for getting either a specific or an arbitrary value loaded into a register. In this day of pipelined machines This is sort of reminiscent of the good old days, programming in 7080 Autocoder. Boeing insisted that the programmers use a MOVE macro because there were 26 different ways to move data from one storage location to another. It was expected that most programmers would use either their favorite way or the first one that popped into their heads if left on their own. The macro chose the optimal way, depending on the operand definitions. ________________________________
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stanley Rarick Sent: Friday, December 01, 2006 10:37 PM To: [email protected] Subject: Re: CMSCALL return code For a return code, LA R15,value is *much* faster than a L - only one storage fetch. Schuh, Richard wrote: I really would not have left it to chance, I would have defined a word-aligned constant rather than using a literal. However, it might not have been as chancy as it may seem. The literal pool is doubleword aligned and boundary alignment may have been a factor in determining where the literal resided. I would like to think that the 8-byte multiples are put at the front, the 4-byters next, then the twos followed by everybody else. In looking at an assembly listing, that seems to be the sequence. The first two literals in the program are =x'0000A00', the next =x'FF', etc. In the literal pool, all 4 byte entries (there were no 8 byte literals) precede the two byte literals and then come the ones of only 1 byte. Within each of these groups, the literals appear in the order in which they were defined. There were no long strings defined as literals in the particular listing. -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Don Russell Sent: Tuesday, November 21, 2006 3:46 PM To: [email protected] Subject: Re: CMSCALL return code Schuh, Richard wrote: I agree, it does seem non-intuitive. The initial SR R15,R15 was undoubtedly preparing for a default rc of zero. How the non-zero rc gets put into the register later is largely a matter of taste. In this case I probably would have chosen L R15,=X'...' - a habit learned, when machines were slower, based on the knowledge that they were mostly optimized for the LOAD instruction vs. any other way of putting data from memory into a register. If your habit was to use L Rx,=X'...' you were probably lucky in the old days.... the =X literal would not necessarily be word-aligned, causing two fetches to load the register, or, in the days when alignment really mattered... a program exception. Better to use L R15,=A(X'...') if alignment is a concern and you want to use literals. Then the literal IS aligned on a fullword boundary. The initial SR 15,15 is unlikely to be setting the default return code.. .it's clearing the register preparing for the different option bytes to be OR'd in. I agree the macro could (should?) have generated a single L instruction instead, but then what nits would we have to discuss? :-)
