[00a69b48f3bb-dmarc-requ...@listserv.uga.edu]
Sent: Wednesday, February 2, 2022 10:22 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers
On Tue, 1 Feb 2022 22:36:48 -0500, Tony Thigpen wrote:
>Tom,
>
>I have reread and reread it. If what Michael seems to
On Tue, 1 Feb 2022 22:36:48 -0500, Tony Thigpen wrote:
>Tom,
>
>I have reread and reread it. If what Michael seems to be saying is
>true, then your charts are wrong. But(!), I think your charts are
>right and Michael's wording is giving me problems. I thought I
>had this all worked out until
Tom,
I have reread and reread it. If what Michael seems to be saying is true,
then your charts are wrong. But(!), I think your charts are right and
Michael's wording is giving me problems. I thought I had this all worked
out until Michael's 1/31/22, 16:37 (EST) post where he said:
"I put
On Mon, 31 Jan 2022 17:02:37 -0500, Tony Thigpen wrote:
>Michael,
>
>Again, bear with me. I am trying to wrap my head around this stuff.
>
>On your last point about using F7SA for a 144 byte save area. You
>said you put F7SA in the 144 byte area because the previous save
>area was a 216 bytes
On Mon, 31 Jan 2022 16:19:23 -0500, Tony Thigpen wrote:
>a) If it's FxSA, then the forward/backward pointers are at x80-x8F,
>thus we can safety STMG R14,R12,8(R13) because that area is before
>the forward/backward pointers. We also know that we can store a
>new forward pointer at x88.
What
Peter F wrote:
. . . each save area indicates how the BACKCHAIN POINTER WAS (not
"registers were") stored by the program that created that area.
No, it indicates BOTH how the backchain pointer was stored *and* also how
the caller's registers were stored.
When you create a save area, it is
Thigpen
Sent: Monday, January 31, 2022 3:19 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers
The part that still 'bugs me' about all the explanations, is the
statement that the tag does not tell you *anything* about how the area
'was used' or even 'can be used
MBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers
I will recklessly attempt to demonstrate the knowledge acquired from this
thread by confidently stating...
No, the only thing you know is that if word1 is FxSA something then that save
area is at least 144 bytes.
For exa
List On Behalf
Of Tony Thigpen
Sent: Monday, January 31, 2022 3:19 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers
The part that still 'bugs me' about all the explanations, is the
statement that the tag does not tell you *anything* about how the area
'was used
onie
Sent: Saturday, January 29, 2022 4:14 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers
* The fact that is so confusing implies that the Assembler Services
Guide is not doing a good job of explaining it. It is hard to
understand because it defies expectati
Mainframe Assembler List On Behalf
Of Mark Boonie
Sent: Saturday, January 29, 2022 4:14 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers
> * The fact that is so confusing implies that the Assembler Services
> Guide is not doing a good job of explaining
> * The fact that is so confusing implies that the Assembler Services
> Guide is not doing a good job of explaining it. It is hard to
> understand because it defies expectations. What you *expect* is that
> you have a value that describes the format of a structure, and by
> implication, its
pectations. What you *expect* is that you have a value that describes
the format of a structure, and by implication, its length.
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Seymour J Metz
Sent: Thursday, January 20, 2022 11:22 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.ED
lto:ASSEMBLER-LIST@LISTSERV.UGA.EDU>> On
Behalf Of Tony Thigpen
Sent: 27 January 2022 22:42
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU<mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU>
Subject: Re: Saving Caller's 64-bit Registers
ATTENTION: External Email - Be Suspicious of Attachments, Links and Requests
for
] on behalf
of Tom Marchant [00a69b48f3bb-dmarc-requ...@listserv.uga.edu]
Sent: Thursday, January 27, 2022 4:27 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers (was "...Regsiters")
On Thu, 27 Jan 2022 20:39:26 +, Seymour J Metz wrote:
u/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Ed Jaffe [edja...@phoenixsoftware.com]
Sent: Thursday, January 27, 2022 5:06 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers
On 1/27/2022 11:20
In some of those cases, perhaps cheating would work. Assuming 64-bit
registers R15, R0, and R1 are insufficient (if they are truly volatile
in your application), perhaps you have an unused register that can hold
the high half of another register which you'll use as a 64-bit register.
On
It might be worth noting that the normal official linkage when ARs need to
be saved is to use the linkage stack.
We internally do use some 144-byte save areas for GR low-half plus ARs.
That never made it into the linkage conventions.
Tony T wrote:
First a basic question on F8SA. The AR-regs at
Gil wrote:
When did the rules change? In days of yore I was led to believe that any
program
that could be invoked with /STEP EXEC PGM=... could instead be invoked by
LINK
With a 72-byte save area. In fact, ini Assembler Services Guide V2R5, I
read:
• Caller-provided save area
A
Ed Jaffe wrote on 1/27/22 5:06 PM:
On 1/27/2022 11:20 AM, Tony Thigpen wrote:
The question has nothing to do with "what if +4 is zeros." It is "what
if +4 has one of the standard literals."
I gotta ask...
From a purely practical standpoint, would you or anyone really want to
maintain
On 1/27/2022 11:20 AM, Tony Thigpen wrote:
The question has nothing to do with "what if +4 is zeros." It is "what
if +4 has one of the standard literals."
I gotta ask...
From a purely practical standpoint, would you or anyone really want to
maintain bifurcated code that took different
Tom,
I am looking at your 2012 presentation.
It would be very helpful if you color-coded the different areas with an
indication of who can write to them.
For example, in an F8SA, code the fields that are set/used by the
program allocating the save-area red. Thus indicating that those bytes
On Thu, 27 Jan 2022 20:39:26 +, Seymour J Metz wrote:
>I don't understand "That is not what F8SA was designed for.";
>the text you cited confirms that an F8SA is used by routines that
>need to save ARs.
No, that isn't what it says. It says "F8SA area provides space into
which a program
Re: Saving Caller's 64-bit Registers (was "...Regsiters")
On Thu, 27 Jan 2022 18:02:07 +, Seymour J Metz wrote:
>> What I did say is "A program that saves its caller's registers in
>> standard 72-byte format is expected to set offset 4 of the save
>> area that it
On Thu, 27 Jan 2022 18:02:07 +, Seymour J Metz wrote:
>> What I did say is "A program that saves its caller's registers in
>> standard 72-byte format is expected to set offset 4 of the save
>> area that it obtains to the address of the previous save area,
>> regardless of the size of save
Ed,
The question has nothing to do with "what if +4 is zeros." It is "what
if +4 has one of the standard literals."
The statement is "If I am called and I see one of the standard save area
literals at +4, then I know I can store my registers using STMG
R14,R12,8(R13)."
I know this because
On Jan 26, 2022, at 09:56:18, Peter Relson wrote:
>
> Some more info from the REXX folks:
>
> The savearea passed to programs invoked via ADDRESS LINK, LINKMVS, or
> LINKPGM was extended to pass
> a 144-byte savearea to the caller by APAR OA44581 (whenever that became
> available). ...
>
On 1/27/2022 8:56 AM, Tony Thigpen wrote:
Ed,
By the 'rules' express in this thread, if the caller places one of the
literals at x'04', he then *must* place the back-pointer at offset
x'80'. Is that not what you and others have been saying?
Ugh. I quickly "ripped off" a silly (and stupid)
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers
On 1/27/2022 8:31 AM, Tom Marchant wrote:
> On Thu, 27 Jan 2022 08:05:32 -0800, Ed Jaffe
> wrote:
>
>
> It is easy to get confused, isn't it? +4 is set by the program that
> obtained the save area
/mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Tom Marchant [00a69b48f3bb-dmarc-requ...@listserv.uga.edu]
Sent: Thursday, January 27, 2022 11:52 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Regist
On 1/27/2022 8:31 AM, Tom Marchant wrote:
On Thu, 27 Jan 2022 08:05:32 -0800, Ed Jaffe
wrote:
It is easy to get confused, isn't it? +4 is set by the program that
obtained the save area, not the programs that use it.
Good point. +4 in your caller's save area describes how HE saved HIS
Ed,
By the 'rules' express in this thread, if the caller places one of the
literals at x'04', he then *must* place the back-pointer at offset
x'80'. Is that not what you and others have been saying?
If the back-pointer *must* be at x'80', then the area from x'08'-x'7F'
*must* therefore be a
Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
>of Tom Marchant [00a69b48f3bb-dmarc-requ...@listserv.uga.edu]
>Sent: Thursday, January 27, 2022 9:17 AM
>To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>Subject: Re: Saving Caller's 64-bit Registers (was "...Regsiters"
On Thu, 27 Jan 2022 08:05:32 -0800, Ed Jaffe
wrote:
>On 1/27/2022 6:24 AM, Tony Thigpen wrote:
>> The answer seems to be that, while not fully known, if one of the
>> literals is present, the called program can safely know that they have
>> at least the x'08' to x'7F' are to start double-word
On 1/27/2022 6:24 AM, Tony Thigpen wrote:
The answer seems to be that, while not fully known, if one of the
literals is present, the called program can safely know that they have
at least the x'08' to x'7F' are to start double-word registers. Do you
at least agree to that conclusion?
: Re: Saving Caller's 64-bit Registers (was "...Regsiters")
On Thu, 27 Jan 2022 02:57:11 +, Seymour J Metz wrote:
>> No. A program that saves its caller's registers is F4SA format is expected
>> to set
>> offset 4 of the save area that they obtain to &q
On Thu, 27 Jan 2022 09:55:00 -0400, Peter Relson wrote:
>A program that "saves its caller's registers in standard 72-byte
>format" is not one that (also) saves ARs and/or high halves. That
>would be a program that "saves its caller's low halves in standard
>72-byte format and also saves ARs
IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Peter Relson [rel...@us.ibm.com]
Sent: Thursday, January 27, 2022 8:55 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers
Shmuel wrote
>For running forward, it's a bit stickier. Is a program
Peter,
"You keep saying that "The main important thing, as has been mentioned
so many times, is that the provider of the save area provides space."
One of the outstanding questions that you keep 'going around' is:
"Can the called program (sometimes) know how much area was provided?"
The
On Thu, 27 Jan 2022 02:57:11 +, Seymour J Metz wrote:
>> No. A program that saves its caller's registers is F4SA format is expected
>> to set
>> offset 4 of the save area that they obtain to "F4SA", regardless of the size
>> of the
>> save area that it obtains for the programs that it
Shmuel wrote
>For running forward, it's a bit stickier. Is a program providing a
>144 byte save area expected to format it as FxSA?
As I wrote previously, you cannot in general "run forward". You could if
you know exactly what the target programs are doing (which is unlikely
unless you own
List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Tom Marchant [00a69b48f3bb-dmarc-requ...@listserv.uga.edu]
Sent: Wednesday, January 26, 2022 9:33 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers (was "...Regsiters")
On Thu, 27 Jan 2022 01:26:
On Thu, 27 Jan 2022 01:26:37 +, Seymour J Metz wrote:
>Is a program providing a 144 byte save area expected to
>format it as FxSA?
No. A program that saves its caller's registers is F4SA format is expected to
set offset 4 of the save area that they obtain to "F4SA", regardless of the
]
Sent: Wednesday, January 26, 2022 10:04 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers (was "...Regsiters")
Tom,
Sorry, just trying to get this correct.
First a basic question on F8SA. The AR-regs at offset x'90', are they
AR-regs stored by B or by
...@phoenixsoftware.com]
Sent: Wednesday, January 26, 2022 10:37 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers (was "...Regsiters")
Tom,
You've provided an excellent tutorial describing *exactly* what's
documented in the books about how this is all supposed to work.
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Tom Marchant [00a69b48f3bb-dmarc-requ...@listserv.uga.edu]
Sent: Wednesday, January 26, 2022 12:03 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers (was "...Regsiters&qu
Tony wrote:
1) What is "B's save area"?...or is it the save area allocated
by B and used by C when C receives control?
It is the "or" -- B's save area is the save area allocated by B. B
provides that to what it calls (such as C). It will (as filled in by C)
contain B's registers at the time
On Jan 26, 2022, at 10:57:44, Tom Marchant wrote:
>
> ATTACH(X) always passes a 144-byte save area since about z/OS 2.3.
> EXEC PGM= invokes your program with ATTACH.
>
When did the rules change? In days of yore I was led to believe that any
program
that could be invoked with /STEP EXEC
ATTACH(X) always passes a 144-byte save area since about z/OS 2.3.
EXEC PGM= invokes your program with ATTACH.
--
Tom Marchant
On Wed, 26 Jan 2022 10:40:30 -0700, Paul Gilmartin wrote:
>Does //STEP EXEC PGM=... nowadays pass a 144-byte savearea whether >the PGM
>needs it or not?
On 1/26/2022 9:13 AM, Martin Trübner wrote:
>> Can the REXX folks say anything about whether any changes to
savearea size also affect VSE? It sounds like not.
I am pretty deep into VSE as well as REXX... there hasn't been any
word about 64 bits for programs - and now that 21 CSW is handling
On Jan 26, 2022, at 09:56:18, Peter Relson wrote:
>
> Some more info from the REXX folks:
>
Thanks.
> The savearea passed to programs invoked via ADDRESS LINK, LINKMVS, or
> LINKPGM was extended to pass
> a 144-byte savearea to the caller by APAR OA44581 (whenever that became
> available).
>
The 2018 presentation is at
https://www.share.org/DesktopModules/EasyDNNNews/DocumentDownload.ashx?portalid=0=761=2369=2094
The 2012 presentation contains commentary that is missing from the 2018
presentation.
>> Can the REXX folks say anything about whether any changes to
savearea size also affect VSE? It sounds like not.
I am pretty deep into VSE as well as REXX... there hasn't been any word
about 64 bits for programs - and now that 21 CSW is handling it (or
will soon), I doubt that it will
Tony,
The access registers are defined in the F8SA format for consistency with the
F7SA format. It is not intended that a program allocate a 288-byte save area
and save the access registers starting at x'90'. The intent of F8SA is that a
64-bit program that is passed only a 72-byte save area
Can the REXX folks say anything about whether any changes to savearea
size also affect VSE? It sounds like not. The original poster works in
a VSE environment.
On 2022-01-26 11:56 a.m., Peter Relson wrote:
Some more info from the REXX folks:
The savearea passed to programs invoked via
On 1/26/2022 8:17 AM, Tom Marchant wrote:
Thanks for the correction, Ed. I'm surprised there weren't more errors in it.
Actually, I did present a SHARE session on this twice. Once in 2012 and again
in 2018, titled, Saving Your Caller's Registers - Not Your Father's Save Area.
My bad for not
Perchance a link to the .pdf ?
Or both if they are significantly different ...
Cheers
On Wed, Jan 26, 2022, 11:17 Tom Marchant <
00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote:
> Thanks for the correction, Ed. I'm surprised there weren't more errors in
> it.
>
> Actually, I did present
Thanks for the correction, Ed. I'm surprised there weren't more errors in it.
Actually, I did present a SHARE session on this twice. Once in 2012 and again
in 2018, titled, Saving Your Caller's Registers - Not Your Father's Save Area.
--
Tom Marchant
On Wed, 26 Jan 2022 07:37:36 -0800, Ed
On 1/26/2022 8:03 AM, Mark Boonie wrote:
This provides the cornerstone of a GREAT SHARE presentation you oughtta
give wunna these days!
Funny, I'm looking at a SHARE presentation, from August 2012, that I refer
to when I have questions about how this stuff works. It's by some guy
named --
> This provides the cornerstone of a GREAT SHARE presentation you oughtta
> give wunna these days!
Funny, I'm looking at a SHARE presentation, from August 2012, that I refer
to when I have questions about how this stuff works. It's by some guy
named -- well, what do you know -- Tom Marchant.
Tom,
You've provided an excellent tutorial describing *exactly* what's
documented in the books about how this is all supposed to work.
I did find one typo. After "D" returns and "E" gets invoked by "B", you
have "D" saving registers. That should say "E". We knew what you meant.
This
Tom,
Sorry, just trying to get this correct.
First a basic question on F8SA. The AR-regs at offset x'90', are they
AR-regs stored by B or by C?
Second, I want to ask about your last two paragraphs.
If B received a 72-byte area and needs to save either 64bit or aregs, it
will need to create
1) B's save area is the save area obtained by program B. While B is running,
B's save area address is in register 13. Any program (or system service that
requires it) that is called by B will use that save area to save the registers
upon entry to that program, so that it can restore those
expect 72-byte save areas and both use
the upper words of general registers?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Peter Relson [rel...@us.ibm.com]
Sent: Tuesd
_
>From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
>of Peter Relson [rel...@us.ibm.com]
>Sent: Tuesday, January 25, 2022 9:35 AM
>To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>Subject: Re: Saving Caller's 64-bit Registers (was "...Regsiters")
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Peter Relson [rel...@us.ibm.com]
Sent: Tuesday, January 25, 2022 9:35 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers (was "...Regsiters")
Shmuel wrote
...I don't
Really? So you don't care that your 64-bit C program uses XPLINK-64 program
linkage with its stack above the bar? As a result, it can only call an amode 64
program.
I heard somewhere that Rome wasn't built in a day.
--
Tom Marchant
On Tue, 25 Jan 2022 12:06:05 -0700, Paul Gilmartin wrote:
On Jan 25, 2022, at 11:03:23, Ed Jaffe wrote:
>>>
>> Fixing it should take precedence over documenting it. Through a half-century
>> IBM has documented too many things that should have been fixed.
>
> Your assertion suggests the existing functionality broken. It's not.
>
> There is nothing
On 1/25/2022 9:31 AM, Paul Gilmartin wrote:
On Jan 25, 2022, at 09:24:10, Peter Relson wrote:
The REXX team indicates that the current savearea size for a called
routine is 72 bytes.
This will get documented. Thanks Shmuel for submitting the update request.
Fixing it should take precedence
On Jan 25, 2022, at 09:24:10, Peter Relson wrote:
>
> The REXX team indicates that the current savearea size for a called
> routine is 72 bytes.
> This will get documented. Thanks Shmuel for submitting the update request.
>
Fixing it should take precedence over documenting it. Through a
The REXX team indicates that the current savearea size for a called
routine is 72 bytes.
This will get documented. Thanks Shmuel for submitting the update request.
Maybe the size will change in a release, such that you can eventually get
to the point of relying on a larger size if you know you
Shmuel wrote
...I don't understand the issue for running the forward chain, assuming
that all called routines have set the forward pointer, other than
detecting the end of the chain.
If +4 (word 2) is on a word boundary then the save area is either unused
or is 72 bytes. If word 2 is FxSA
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
"IBM Mainframe Assembler List" 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
Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Dave Clark [dlcl...@winsupplyinc.com]
Sent: Thursday, January 20, 2022 10:29 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers
"IBM Mainframe Assembler List" wrote on
01/20/2022 09:36:03
List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Schmitt, Michael [michael.schm...@dxc.com]
Sent: Thursday, January 20, 2022 10:56 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers
The problem is that the new save area formats are not compatible with the
72
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers
"IBM Mainframe Assembler List" wrote on
01/20/2022 10:43:30 AM:
> As I remember, all are saved. It's not a simple 'add to the end', they
> redefined the front fullwords too.
Where can I fi
[ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Dave Clark [dlcl...@winsupplyinc.com]
Sent: Thursday, January 20, 2022 10:59 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers
"IBM Mainframe Assembler List" wrote on
01/20/2022 10:56:17 AM:
> The problem is
"IBM Mainframe Assembler List" wrote on
01/20/2022 10:56:17 AM:
> The problem is that the new save area formats are not compatible
> with the 72-byte save area format, so you can't use them in amode 31
> unless you control both the calling and called programs. And they're
> not supported by
Assembler List On Behalf
Of Steve Smith
Sent: Thursday, January 20, 2022 9:52 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers
I don't know what you found, but that's incorrect. A standard Format-4
save area is 144 bytes, and there are additional formats (5-8
"IBM Mainframe Assembler List" wrote on
01/20/2022 10:51:30 AM:
> I don't know what you found, but that's incorrect. A standard Format-4
> save area is 144 bytes, and there are additional formats (5-8) that can
> hold combinations of ARs and high-halves.
>
> As previously mentioned, the
"IBM Mainframe Assembler List" wrote on
01/20/2022 10:43:30 AM:
> As I remember, all are saved. It's not a simple 'add to the end', they
> redefined the front fullwords too.
Where can I find a description of the elements of the register
save area then? But, for now, I will stick
I don't know what you found, but that's incorrect. A standard Format-4
save area is 144 bytes, and there are additional formats (5-8) that can
hold combinations of ARs and high-halves.
As previously mentioned, the Assembler Services Guide defines all this.
sas
On Thu, Jan 20, 2022 at 10:30 AM
As I remember, all are saved. It's not a simple 'add to the end', they
redefined the front fullwords too.
Tony Thigpen
Dave Clark wrote on 1/20/22 10:29 AM:
"IBM Mainframe Assembler List" wrote on
01/20/2022 09:36:03 AM:
"IBM Mainframe Assembler List" wrote
on
01/19/2022 06:05:12 PM:
At
"IBM Mainframe Assembler List" wrote on
01/20/2022 09:36:03 AM:
> "IBM Mainframe Assembler List" wrote
on
> 01/19/2022 06:05:12 PM:
> > At program entry:
> >
> > STMH 2,14,your-high-halves-save-area 13 fullwords for 2-14 high
halves
> >
> > At program exit:
> >
> > LMH 2,14,
85 matches
Mail list logo
