A not unreasonable solution is to create a 144-byte save area for your own
subroutine and calls you will make (or at least 72 bytes larger than whatever
kind of save area you are setting up for subroutines that you will call) and
save / restore the caller's high-halves at entry and exit of your program using
the second (or last) 72-byte part of your 144-byte (or larger) area.
Then at least the caller's high halves are right next to your save area. The
standard dump print routines won't format them, but at least you can find them
easily in the dump from the save area address.
Not "standard" to be sure, but reasonable IMHO.
Something like this (and obviously needing some tweaking depending on your
entry and exit code):
WORKAREA DSECT ,
CALLSAVE DS CL144
. . . . REST OF YOUR DYNAMIC WORK AREA HERE
MYPROG CSECT ,
. . . . AT YOUR ENTRY POINT AFTER OBTAINING AREA FOR CALLSAVE
STMH 13,12,CALLSAVE+80 OR CALLSAVE+L'CALLSAVE-(16*4)
, , , , THE REST OF YOUR CODE HERE
. . . . THEN IN NORMAL EXIT CODE AFTER RESTORING CALLER'S LOW HALVES
LMH 13,12,CALLSAVE+80 OR CALLSAVE+L'CALLSAVE-(16*4)
You might or might not want to reload the high half of R15 if you are returning
a value in the low half, but that is kind of application-specific whether the
high half of R15 needs to be restored in that case or not.
Peter
-----Original Message-----
From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> On Behalf
Of Schmitt, Michael
Sent: Wednesday, September 30, 2020 4:04 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Register saving formats
EXTERNAL EMAIL
Let's say you want to create an amode 31 assembler program that uses 64-bit
instructions that modify the high words of registers. Per the Assembler
Services Guide, such a program must preserve the high halves of GPR 2-14. But
where do you preserve them?
There are save area formats that can hold the high halves, but the problem is
that none of them are backwardsly compatible with the standard 72-byte save
area. So, you can't use any of these formats unless you are in full control of
*every* subprogram that you call. Otherwise, if you call a subprogram that
expects a 72-byte save area, it will corrupt your non 72-byte area.
[This is confusing but it is because with the 64-bit save area formats for
amode 31 programs you are saving your low-halves in the caller-provided save
area as normal, but you save the high-halves in *your* save area.]
This means that the only option is to use the standard 72-byte save area and
store the high-halves yourself in some other storage that you provide,
disconnected from the standard save area chain. In fact, the COBOL 5 and COBOL
6 Migration Guides specifically say *not* to use the standard z/OS conventions
for saving 64-bit registers, and instead recommends saving the high-halves in
your own storage in this fashion.
But if you don't use standard z/OS conventions then diagnostic aids won't be
able to find and report the saved high-halves. I'm thinking here of SYSUDUMPs,
IBM Fault Analyzer, Compuware Abend-AID, etc.
This is somewhat mitigated by the fact that since the program is amode 31, the
GPR registers wouldn't contain any 64-bit *addresses*, just 64-bit data values,
and therefore there wouldn't be a need for the diagnostic aid to use the saved
register value as an address.
My question is: Why was IBM unable to design a standard convention for saving
64-bit registers in amode 31 programs that is backwardsly compatible with
unchanged programs? Is there really no possible way that it could be
accomplished?
--
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
