R14-R1 or all? All that the documentation says are supposed to be unaltered, assuming (1) the documentation exists and (2) it discusses altering of caller's registers.
Where documented? I don't know. I don't do VSE. We were talking about VSE in this thread. The only doc I have is for z/OS. In that doc are several commonly used system services (e.g., STORAGE , previously spelled "GETMAIN/FREEMAIN) that are known not to save and restore the high-order halves of GPRs. I assume that whatever happens in z/OS system services could also happen in VSE system services, ergo my suggestion to check the VSE doc and not necessarily to trust the doc. -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Binyamin Dissen Sent: Monday, January 17, 2011 4:35 PM To: [email protected] Subject: Re: Subroutines, save areas and 64bit On Mon, 17 Jan 2011 22:08:15 +0000 Bill Fairchild <[email protected]> wrote: :>The z/OS system service GETMAIN does not preserve the high-order half of GP registers, and there are probably others in z/OS like that. Check the doc on each VSE system service that you use. When in doubt, save all 16 GP regs with a STMG before you call a system service and reload all of them, except for any that are supposed to be altered by the service (typically R15-R1), after you get control back from the system service. I/O macros are also system services (GET, PUT, OPEN, EXCP, etc.). Huh? Do you mean R14-R1 or all? If so,m where is this documented? :>-----Original Message----- :>From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Tony Harminc :>Sent: Monday, January 17, 2011 2:23 PM :>To: [email protected] :>Subject: Re: Subroutines, save areas and 64bit :> :>On 17 January 2011 15:18, McKown, John <[email protected]> wrote: :>> First question: Does your code use 64-bit instructions? If not, then why would you need to worry about saving the high word of the caller's registers? If you don't modify it, then it doesn't need to be saved, does it? :> :>Just don't issue a GETMAIN... :> :>Tony H. -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies.
