It drives me nuts when they trash the ARs (14-1) on a service call. I never saw it documented before but I was sure it was somewhere.
Chuck Arney On Aug 30, 2013, at 5:47 PM, Ed Jaffe <[email protected]> wrote: > On 8/30/2013 3:06 PM, Paul Gilmartin wrote: >> Isn't there one hole in this scheme, discussed in IBM-MAIN several >> months ago, that GETMAIN (STORAGE OBTAIN, whatever) called in 31-bit >> mode modifies the high half of its result register? This still causes >> no problems for a pure AMODE 31 program or for a pure AMODE 64 program, >> but only when an AMODE 64 program calls an AMODE 31 program which saves >> and restores only 31-bit registers but returns with the high parts >> modified. > > You are correct about the behavior. However, it is not a "hole" since > the high-halves of registers 15-1 are considered volatile over a call to > another program or service. > > <Assembler Services Guide> > Unless otherwise defined by the individual interface, the calling program > should expect, upon return, that > > o The low halves (Bits 32-63) of GPRs 2 through 13 are unchanged > o The high halves (Bits 0-31) of GPRs 2 through 14 are unchanged > o ARs 2 through 13 are unchanged > o FPRs 8 through 15 are unchanged; The Floating Point Control (FPC) > Register is unchanged with the exception of two fields: the IEEE > exception flags and the data exception code (DXC). > o When return information is provided in GPR 0, 1, and/or 15 (for > example return and reason codes), only bits 32-63 of the register > contain the returned value. > </Assembler Services Guide> > > -- > Edward E Jaffe > Phoenix Software International, Inc > 831 Parkview Drive North > El Segundo, CA 90245 > http://www.phoenixsoftware.com/ >
