>BAKR is quite slow compared to normal save area chaining processes
This remains true. BAKR has more to do. So does PR. If performance is your
goal, STM(G)/STAM is faster.
BAKR/PR is likely a good choice for initial entry to an application
(especially one where you cannot change the caller to
And the linkage stack is not supported by Language Environment.
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Farley, Peter x23353
Sent: Wednesday, October 7, 2020 1:12 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Register saving formats
True, but my
use of
BAKR / PR that I remember seeing.
Peter
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Ituriel do Neto
Sent: Wednesday, October 7, 2020 12:00 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Register saving formats
Hi,
Maybe i didn't understand correctly
Hi,
Maybe i didn't understand correctly, but if you use BAKR and PR, don't need to
worry about saveareas sizes. It takes care of everything including PSW, AR.
Regards
Ituriel
Em sexta-feira, 2 de outubro de 2020 09:44:40 BRT, Peter Relson
escreveu:
...but the problem is that none of
...but the problem is that none of them are backwardsly compatible with
the standard 72-byte save area.
Totally untrue. The documented 144-byte (and 216-byte) save areas can be
passed just fine to a routine that uses a 72-byte save area. That is why
they were designed the way they were.
Register saving formats for z/OS are very clearly described in the Linkage
Conventions section of
z/OS MVS Programming: Assembler Services Guide.
Some mappings are provided in IHASAVER.
Peter Relson
z/OS Core Technology Design
30, 2020 6:15 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Register saving formats
What if:
a) your function is (directly or indirectly) recursive?
b) your program needs to be RENT?
Mix this problem with the problem of dynamically allocating save
area and it gets to be quite an issue
://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List on behalf
of Schmitt, Michael
Sent: Wednesday, September 30, 2020 4:04 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Register saving formats
Let's say you want to create an amode 31 assembler
What if:
a) your function is (directly or indirectly) recursive?
b) your program needs to be RENT?
Mix this problem with the problem of dynamically allocating save
area and it gets to be quite an issue.
The Dignus C runtime makes the same guarantee of the high-halves that
the IBM Assembler
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 preserv
You are mixing up two different issues.
If a program is using 64 bit registers and wishes them to be saved across
subroutine calls, it must provide one of the 64 bit save areas.
The 31 bit subroutine can treat the 64 bit save area as a 31 bit one, i.e., it
can use STM 14,12,12(13) and set
, September 30, 2020 4:29 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Register saving formats
Caution! This message was sent from outside your organization.
I use the IBM guidelines and haven't had a problem. A called program that
assumes it received a 72-byte save area does not corrupt
I use the IBM guidelines and haven't had a problem. A called program that
assumes it received a 72-byte save area does not corrupt the large save
area, it just isn't "correct". But it causes no problem.
I don't see your distinction between the save areas that provide space for
the caller's
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
14 matches
Mail list logo
