Are we to conclude from that this discussion that this is a reliable way
to ensure that an AMODE 31 subroutine returns control to its caller in
the correct amode?
From Binjamin's response, it appears that checking the opcode of the
previous instruction was unnecessary and perhaps, depending on the speed
of BSM, actually slowed down the routine.
Tony, I appreciated the "quarks" for "quirks" typo. It's like we're
going way deeper than just the bits and electrons level!
Gary
On 2020-08-12 6:18 a.m., Tony Thigpen wrote:
I talked to the author of the code.
1) The original program that this code was coded within actually was a
glue phase that replaced a vendor provided phase that was always
called using an api macro provided by the vendor to the customer.
2) At one point, the vendor was 24bit, but later changed to 31bit.
Also, the vendor changed from BALR to BASSM (with a short use of BSM
during one intermediate update).
3) This glue phase has always calling additional modules using BASSM
and those modules were always 31bit.
4) The original vendor macro was used in a lot of programs and they
did not want to recompile everything every time the vendor changed the
api macro. So, the glue code had to handle a lot of quarks in how it
was called.
So, the glue phase had to handle the following situations over several
releases of the vendor product:
1) 24bit using BALR
2) 31bit using BALR
3) 31bit using BSM
4) 31bit using BASSM
Eventually, his special entry macro was used by others even when they
did not need the special functionality.
Tony Thigpen
Martin Truebner wrote on 8/12/20 5:15 AM:
Binjamin,
your sequence
LA 14,0(,14) Fix-up address (in case 24 bit)
BSM 14,0 Now BSM 0,14 will restore the current amode
Will clear the amode-bit and BSM will set to that mode (0=24) and go
there.
If you are very lucky you are never called in 31 bit mode then the code
will not do any harm
If you are called in 31 bit mode then you could be lucky and the
truncated address is nonsense in 24 bit mode- but ....
--
Martin Trübner; everything around "PoOps of z/arch"
Teichstraße 39E
D-63225 Langen
F: +49 6103 71254
M: +49 171 850 7132
E: [email protected]
Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone:+1.613.523.5500 x216
Email: [email protected]
Visit us online at www.DKL.com
E-mail Notification: The information contained in this email and any
attachments is confidential and may be subject to copyright or other
intellectual property protection. If you are not the intended recipient, you
are not authorized to use or disclose this information, and we request that you
notify us by reply mail or telephone and delete the original message from your
mail system.
