Re: CMSCALL return code
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'A00', 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? :-)
Re: CMSCALL return code
On 21 Nov 2006 at 17:32, Schuh, Richard wrote: 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. I was going to say the same thing, but a bit more definitively. The following quotation is taken from the HLASM 5 ref manual, at http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/asmr1010/5.31.1?SHELF=DT=20040728153937 Each literal pool has five segments into which the literals are stored (a) in the order that the literals are specified, and (b) according to their assembled lengths, which, for each literal, is the total explicit or implied length, as described below. | The first segment contains all literal constants whose assembled | lengths are a multiple of 16. The second segment contains those whose assembled lengths are a multiple of 8, but not of 16. The third segment contains those whose assembled lengths are a multiple of 4, but not a multiple of 8. The fourth segment contains those whose assembled lengths are even, but not a multiple of 4. The fifth segment contains all the remaining literal constants whose assembled lengths are odd. | Since each literal pool is aligned on a SECTALGN alignment, this | guarantees that all literals in the second segment are doubleword aligned; | in the third segment, fullword aligned; and, in the fourth, halfword | aligned. Don Russell also said: 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 ... problems ;-) I believe the current literal pool alignment behavior has been around for a pretty long time. I went now to look it up in the ref, but it is how I remember being taught in the old days of the 70s. Shimon -- ** ** Shimon Lebowitzmailto:[EMAIL PROTECTED] VM System Programmer . Israel Police National HQ. http://www.poboxes.com/shimonpgp Jerusalem, Israel phone: +972 2 530-9877 fax: 530-9308 ** **
