[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
The first program provided only a 72-byte save area.
The second program needs to save the 64-bit registers but cannot
use F4SA because it wasn't provided a 144-byte save area. So it
allocates a 216-byte save area and saves the high halves starting at
x'90' in its own save area. This leaves
ed only a 72-byte save area.
The second program needs to save the 64-bit registers but cannot
use F4SA because it wasn't provided a 144-byte save area. So it
allocates a 216-byte save area and saves the high halves starting at
x'90' in its own save area. This leaves 144 bytes for programs th
its caller's registers. There is no back
chain pointer. The size of the save area is whatever is needed by the programs
that it calls. F1SA was defined and documented for use with the Linkage Stack
in MVS/ESA, long before there were any 64-bit registers. At that time, a
program that marked its save ar
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
(F4SA) and uses the F5SA to store the 64 bit registers. But,
as explained in this email thread, if you call a program that *does not know
for a fact* that it is receiving a 144-byte or greater save area, then that
program will treat the F5SA area as a 72-byte save area, and thus the layout
that is expecting a 144 byte
Format 4 save area (F4SA) and uses the F5SA to store the 64 bit registers. But,
as explained in this email thread, if you call a program that *does not know
for a fact* that it is receiving a 144-byte or greater save area, then that
program will treat the F5SA area
> * 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 2022-01
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
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). Programs invoked as REXX functions or subroutines are still
passed
a
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
, and offset x'88' of B's save area
is set to the address of D's save area.
Now we have:
A's save area contains the low halves of the registers on entry to B. Offset 8
is the address of B's save area.
Offset 4 of B's save area contains "F5SA" and offset x'80' points back to A's
save
.
Offset 4 of B's save area contains "F5SA" and offset x'80' points back to A's
save area, and offset x'88' points to D's save area. The 64-bit registers upon
entry to D are in B's save area, starting at offset 8. The high halves of the
registers on entry to B are still stored in B
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
-bit Registers
"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,
"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,
Shmuel wrote:
CLCL pair+pair (32)
CLCLE pair+pair (32 or 64)
CLCL should be "(32 or 64)" in this nomenclature.
Basically just about any instruction operand that is located by a register
(it could be via a register pair such as for CLCL, or just a
base-displacement with or without
Dave,
IIRC you are running in a pretty old VSE.
So here is something that occured to me when you asked for saving:
VSE 4.x had a very nasty habit of setting all high order words of grade
registers to FF on a path thru the dispatcher.
I found this when developing support for 64 bits for
Subject: Re: 64-bit registers (was: Unsigned Binary Formats)
Um yeah... for approximately 21 years.
sas
On Wed, Jan 19, 2022 at 1:45 PM Dave Clark wrote:
> "IBM Mainframe Assembler List" wrote on
> 01/19/2022 01:00:07 PM:
> > I'd suggest you clear the high-order wo
"IBM Mainframe Assembler List" wrote on
01/19/2022 02:16:55 PM:
> Um yeah... for approximately 21 years.
>
> sas
Well those of us constantly on older hardware and told to code in
COBOL most of the time don't get to play as often with the newer assembler
stuff. ;-b
Sincerely,
List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Dave Clark [dlcl...@winsupplyinc.com]
Sent: Wednesday, January 19, 2022 1:44 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: 64-bit registers (was: Unsigned Binary Formats)
"IBM Mainframe Assembler List" wrote on
01/19/2022 01:00:07
Um yeah... for approximately 21 years.
sas
On Wed, Jan 19, 2022 at 1:45 PM Dave Clark wrote:
> "IBM Mainframe Assembler List" wrote on
> 01/19/2022 01:00:07 PM:
> > I'd suggest you clear the high-order word of R2 then use CVDG.
> >
> > Would that work for you?
>
> OK, that brings up a
-LIST@LISTSERV.UGA.EDU
Subject: 64-bit registers (was: Unsigned Binary Formats)
"IBM Mainframe Assembler List" wrote on
01/19/2022 01:00:07 PM:
> I'd suggest you clear the high-order word of R2 then use CVDG.
>
> Would that work for you?
OK, that brings up a question
That's correct. Your greater the 4-byte arithmetic just got easier! If
you use them in an assembler subroutine, you should save the the
incoming 64-bit register and restore it on the way out. There are
details about only saving the high half and it not being necessary for
certain registers, but
M
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: 64-bit registers (was: Unsigned Binary Formats)
"IBM Mainframe Assembler List" wrote on
01/19/2022 01:00:07 PM:
> I'd suggest you clear the high-order word of R2 then use CVDG.
>
> Would that work for you?
OK, that brings up a questio
"IBM Mainframe Assembler List" wrote on
01/19/2022 01:00:07 PM:
> I'd suggest you clear the high-order word of R2 then use CVDG.
>
> Would that work for you?
OK, that brings up a question that I have not had to address
before this. Up till now I've used odd-even register pairs for
On 8/30/2013 12:56 PM, Ward, Mike S wrote:
Hello all, I'm trying to get back into assembler from my old 360 days and I was
reading the POO. In the POO under registers it says that there are 16 GP
registers available to the program. Ok that sounds good so far, but then it
goes on to say that
Mike,
The old 360 instructions are hardwired or micro-coded to operate only on the
low-order 32 bits of the 64-bit registers (32-63), so they continue to work
exactly as they always did.
The new Grande instructions (e.g., LG instead of L, AG instead of A) are
hardwired or micro-coded
@LISTSERV.UGA.EDU] On
Behalf Of Ward, Mike S
Sent: Friday, August 30, 2013 2:56 PM
To: MVS List Server 2
Subject: 64 bit registers
Hello all, I'm trying to get back into assembler from my old 360 days and I was
reading the POO. In the POO under registers it says that there are 16 GP
registers available
Thank you all for responding, it was very enlightening. I obviously have a lot
of reading and testing to do.
Thanks again.
==
This email, and any files transmitted with it, is confidential and intended
solely for the use of the individual or entity to which it is
1 - 100 of 107 matches
Mail list logo
