Using R14 as a temporary code base after a call isn't going to work in
those cases. I'd never heard about using BIC to return (nor can I see much
reason for it). And there are other bizarre ways to return without
restoring R14, which is not actually required by documented conventions.
For BASSM,
"When control is returned to your control section from the called control
section, registers 2-14 contain the same information they contained when
control was passed, as long as system conventions are followed "
I see nothing wrong with BIC for returning from an AMODE 64 caller with an F4SA.
On Nov 29, 2021, at 12:41:51, Ngan, Robert (DXC Luxoft) wrote:
>
> DON'T DO THAT!
> I had to find/redo all our code that did this when our subroutine return
> logic was changed to use a BIC instruction.
>
Which of you violated standard linkage conventions?
My understanding is that R14 is
The assembler services guide doesn't specify what is in (bottom half of) R14
upon return.
Also, on return to an AMODE(64) routine via BASSM/BSM, R14 would have the
low-order bit set.
Robert
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Paul Gilmartin
Sent:
"When control is returned to your control section from the called control
section, registers 2-14 contain the same information they contained when
control was passed, as long as system conventions are followed."
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
DON'T DO THAT!
I had to find/redo all our code that did this when our subroutine return logic
was changed to use a BIC instruction.
Robert
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Steve Smith
Sent: Thursday, November 25, 2021 13:49
To:
On 2021-11-30 00:06, Peter Relson wrote:
I wrote
For z/OS, this question relates to each work unit and the question is
"does the work unit use FPRs 8-15 or VRs?".
If the answer is no, then that work unit does not save/restore those
regs
upon undispatch/redispatch and thus saves some cycles.
I'm not aware of any processor that FP registers beyond what IBM documented.
Certainly non of the functional specs manuals mentioned such a thing.
>From my perspective it was a long way coming, but I'd bet that there are
>people here and on IBM-MAIN who never saw a processor with only 4.
I wrote
For z/OS, this question relates to each work unit and the question is
"does the work unit use FPRs 8-15 or VRs?".
If the answer is no, then that work unit does not save/restore those regs
upon undispatch/redispatch and thus saves some cycles.
"FPRs 8-15" is incomplete/inaccurate
All,
to my knowledge, the FPRs got even numbers only because in the initial
implementation
they existed as register pairs(!) - hence the weird numbering scheme we
still have today :-)
Kind regards,
Abe Kornelis
Op 29/11/2021 om 15:22 schreef Seymour J Metz:
> I'm not aware of any
The is a difference between what registers exist in the hardware and what is
addressable by a S/360 (FSVO) program. Yes, there were processors where the
microcode could address individual fileds within an FP register, but the
instructions implemented in microcode could not do so until very late
I did not think about how this had to happen before you had saved any
registers. (Same issue for @Gary's suggestion, which is basically equivalent to
mine.)
If there is no register that your linkage conventions imply do not need to be
saved (R0?) then you could temporarily save a register at
So an interesting dilemma:
I have a macro that switches between a regular (24/31 bit style) save area
and an extended (64 bit "F4SA") save area. Before saving the registers, I
am checking whether the current save area is old (24/31 bit) or new (64
bit) save area. The original code used CLC
CLRL 04(r13),=C'F4SA' ...you have USING issues, but as long as LTORG is
within +/- 2G, no problem.
I'd go with
LLIHF 0,C'F4SA'
CLHF 0,4(R13)
or
LFH 0,4(R13)
CLIH 0,C'F4SA'
So many ways to skin the cat.
As usual, not tested, subject to typos, memory checks, etc.
sas
On Mon, Nov 29, 2021 at
Well, I messed up CLRL... it is not an SS-like instruction.
If you really can't afford to trash half of any general register, AR0 is a
convenient hidey-hole. It's the appendix of z/Arch, as it appears to have
no functional purpose. If AR0 can't be trashed, then surely you can borrow
a FPR. If
As per the FPR usage thread, you could also save GR(s) to FP registers 0 thru 7.
Robert
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Charles Mills
Sent: Monday, November 29, 2021 18:03
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
I did not
LLILF and C?
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Mark Hammack
Sent: Monday, November 29, 2021 2:52 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
So an interesting dilemma:
I have a
Can you temporarily save one register, load it register with the 4(R13)
and use a CFI?
On 2021-11-29 5:51 p.m., Mark Hammack wrote:
So an interesting dilemma:
I have a macro that switches between a regular (24/31 bit style) save area
and an extended (64 bit "F4SA") save area. Before saving
18 matches
Mail list logo
