Sorry, I assumed z/OS; I don't know what the conventions are in z/VSE.

For z/OS, 128 bytes is enough to store all of the general registers, but it is 
not a standard save area format. 

An additional reason for the standard formats is to get a trace-back on dumps.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf 
of Dave Clark [dlcl...@winsupplyinc.com]
Sent: Thursday, January 20, 2022 12:40 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers

"IBM Mainframe Assembler List" <ASSEMBLER-LIST@LISTSERV.UGA.EDU> wrote on
01/20/2022 12:28:53 PM:
> I'm aware of a 72-byte format and several 144-byte formats; I'm not
> aware of a 128 byte format. 128 bytes would not allow space for both
> a prefix and the top halves of the GRs.


        Yes, a 128-byte savearea is sufficient because the Assembler
Service manual states that a calling program expects upon return:

• The low halves (Bits 32-63) of GPRs 2 - 13 are unchanged
• The high halves (Bits 0-31) of GPRs 2 - 14 are unchanged
• The remaining registers are all unchanged


        The 72-byte savearea provides for the first bullet point and an
additional 56 bytes (for a total of 128 bytes) would provide for the
second bullet point.  So, the only reason for additional savearea space is
if the called program is going to modify the other registers as well as
the general purpose registers.

        The only issue is that in z/VSE I don't know if the caller is
providing a 72-byte savearea or a 128+byte savearea.  So, I have to
compensate for anything above 72 bytes.


Sincerely,

Dave Clark
--
int.ext: 91078
direct: (937) 531-6378
home: (937) 751-3300

Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio  45439  USA
(937) 294-5331




*********************************************************************************************
This email message and any attachments is for use only by the named
addressee(s) and may contain confidential, privileged and/or proprietary
information. If you have received this message in error, please
immediately notify the sender and delete and destroy the message and all
copies. All unauthorized direct or indirect use or disclosure of this
message is strictly prohibited. No right to confidentiality or privilege
is waived or lost by any error in transmission.
*********************************************************************************************

Reply via email to