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
Dave,
your initial request was for conversion of an unsigned 32-bit binary value.
The LGF you are using does sign extension... I'd suggest you use LLGF
to avoid just that ;-)
Additionally, if speed is a concern, you might want to save only the
high halves of registers
when they may be changed
Regardless of the instruction used to load the source register, CVD treats
it as a signed F-word. So any value with bit 32 (high-order bit of lower
half) on will be converted to a negative PD number. So,
CVD R1,DWORD
IF LTR,R1,R1,M
AP DWORD,=P' 4294967296'
ENDIF
The modern ways are much
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
"IBM Mainframe Assembler List" wrote on
01/20/2022 06:30:02 AM:
> Regardless of the instruction used to load the source register, CVD
treats
> it as a signed F-word. So any value with bit 32 (high-order bit of
lower
> half) on will be converted to a negative PD number. So,
That is
"IBM Mainframe Assembler List" wrote on
01/19/2022 08:42:25 PM:
> I strongly recommend sticking to standard linkage conventions, e.g.,
> R1 pointing to a PLIST that points to the binary and decimal fields.
If I were calling an external subroutine then that is exactly what
I would do.
"IBM Mainframe Assembler List" wrote on
01/20/2022 03:17:17 AM:
> your initial request was for conversion of an unsigned 32-bit binary
value.
>
> The LGF you are using does sign extension... I'd suggest you use LLGF
> to avoid just that ;-)
Yes, it was. But I have to handle both
"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, your-high-halves-save-area
Thanks. I take it that I shouldn't presume the caller has
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
"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,
"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
If you're concerned with trace-backs for debugging, you might want to stick
with standard save area formats. They are documented in Assembler Services.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List
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
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
"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
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 Language
Environment.
-Original Message-
From: IBM Mainframe
"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
Chapter 2 of Assembler Services.
--
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 10:53 AM
Just FYI, that link to
MVS Programming: Assembler Services Guide, SA23-1368-50, <
https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5sa231368/$file/ieaa600_v2r5.pdf@page=33>,
Chapter 2 Linkage Conventions describes some of the choices.
should not have the "@page=33" on the end
"IBM Mainframe Assembler List" wrote on
01/20/2022 11:45:55 AM:
> Just FYI, that link to
>
> MVS Programming: Assembler Services Guide, SA23-1368-50, <
> https://urldefense.com/v3/__https://www.ibm.com/servers/
> resourcelink/svc00100.nsf/pages/zOSV2R5sa231368/$file/
>
Sorry; that should have been #page=33. On most browser that fragment will take
you to the first page of chapter 2. Note that 33 is the page number for the
PDF, not the number printed on the page.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
Some of the new formats are used in conjunction with a 72-byte save area, and
you can definitely use them in A31. I don't know what LE supports (OCO delenda
est!).
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler
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.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM
Note in that manual on page 34 of that PDF (page 6 in the book) it says:
When a program receives control as the target of the EXEC statement,
general-purpose register 13
contains the address of a 144 bytes save area, which is provided by the system.
The system starts out your batch program with
"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
25 matches
Mail list logo
