On 4/12/2011 5:38 AM, Peter Relson wrote:
AnyProg csect AnyProg AMODE 64 SYSSTATE AMODE64=YES,ARCHLVL=2 LLGTR 13,13 ensure effective s.a. address is 64 bits stm 14,12,12(13) save right hand (rh) 32-bit regsThis violates the linkage conventions. You have clobbered the high half of register 13 and thus cannot restore it for the caller..
Well, I have sort of clobbered the high half of R13, but according to your book (Assembler Services Guide) ... "Unless otherwise defined by the individual interface, the calling program should expect, upon return, that * The low halves (Bits 32-63) of GPRs 2 through 13 are unchanged * The high halves (Bits 0-31) of GPRs 2 through 14 are unchanged ..." My thinking was: * if I'm passed a save area addres from an AMODE 24 or AMODE 31 program, the address totally fits in the right hand word, so the LLGTR merely ensures the 64-bit value has high order bits of zeros; on the other hand, being invoked by a program running AMODE 64, the instruction does no harm; now R13 has a valid 64-bit address regardless of the AMODE of the calling program
Also, one hopes that you did not care about the high halves of regs 0, 1, and 15 because they were not preserved by GETMAIN.
See above. Also, 0, 1, and 15 are generally not preserved across calls; 0 and 1 being used for input parm addresses if any (and I could have added code to preserve the value in R1 anyway) and 15 is generally used for a return value, if any.
Peter Relson z/OS Core Technology Design
So, I went back to review the point in this thread where we diverged from multiplying doublewords to the concern about save areas. This was John McKown's post of yesterday (4/11) at 2:31 pm according to my mail client. John was positing a case where a subroutine using 64-bit registers in some fashion (if only calculations, then no need for AMODE 64) has to be able to be called by programs that pass 72-byte save areas or 144 byte save areas; since the subroutine can't tell which, it has to assume the smaller area and code for that. Of course, Chris Craddock had the best answer: the subroutine is the driver / definer / decider of the interface, the proper approach is to ensure all callers follow the subroutine's requirements. That being said, I can see John's point about updating the subroutine to use 64-bit instructions then requiring the subroutine's ensuring 64-bit values are preserved, possibly only being passed a 72-byte save area. But again, the proper way to handle that is to create a new version of the subroutine, under a new name, and specifying it must be called with a 144-byte save area provided. Of course, then there's politics. But the response is: you can continue to use the original subroutine as is; if you want better performance, change your code to call the new subroutine with it's stated design interface. And that's the way it should all be handled, and I think you'll agree to that, too. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our new tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html
