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: IBMVM@LISTSERV.UARK.EDU
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? :-)
