Well actually you write SLLG R0,R13,32 - it has three operands and works much
like RLLG, R13 here remaining unchanged.
-Ursprüngliche Nachricht-
Von: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] Im
Auftrag von John McKown
Gesendet: Donnerstag, 27. Juni 2013
Over on IBM-MAIN there is a discussion on linkage conventions, which was
started by me, initially about changing an HLASM program to be RENT. But
all the back and forth about the right way to implement a linkage
convention has made we want a couple of new instructions, which exist on
many other
If what you're really trying to do is to copy the low order 32 bits of
GPR 13 into the high order 32 bits of GPR 0, while leaving the low order
32 bits of GPR 0 unchanged, then the following I-stream will do the job.
RLLG R0,R0,32(0) Exchange the high order and
*
Hmm, what about RISBG R0,R13,0,31,32 - since someone brought up these
instructions? Assuming it's on the CPU of course. Should impress other
programmers no end.
I missed the start of the thread so I'm not sure what the original issue was.
(Another of those reply to sender things caught me out
Unfortunately, those rotate instructions are not implemented on my z9BC.
Looks like I need to do exactly what I want is RISBHG: RISBHG
R0,R13,0,31,32 . If I am reading the book correctly (and it is complicated
to me!), this rotates the contents of R13 32 bits (swaps high low word
values), then
Hmm, what about RISBG R0,R13,0,31,32 - since someone brought up these
instructions?
Assuming it's on the CPU of course. Should impress other programmers no
end.
I missed the start of the thread so I'm not sure what the original issue
was.
The original append was only looking for a
The original append was only looking for a nomenclature suggestion.
However, it also said that RISBG wasn't available, which means ROSBG and
LHLR (which is really RISBHGZ anyway) aren't available either.
- mb
Since the original query was how to document, you could just indicate
that you're
On Thu, 27 Jun 2013 08:24:53 -0500, John McKown wrote:
A hardware PUSHR and POPR (R suffix to avoid conflict
with existing PUSH POP) which can PUSH and POP the general and access
registers onto a stack. This would require a hardware stack, similar to the
Linkage Stack used by PC/PR/BAKR, but one
I fail to see the difference between what you are asking for and BAKR/PR.
BAKR and PC already do a 'hardware' save of the 64-bit registers into
storage that is not accessable by the application. I personally have never
seen a Stack-Full condition and your new instructions could still suffer
from
On 6/27/2013 9:00 AM, Bohn, Dale wrote:
The ONLY difference I do
see is your wish to use it in SRB mode. I would think that the setup
overhead for using ANY type of PUSHR or BAKR for a SRB could significently
slow down a process that is meant to be fast.
We issue BAKR/PR in SRB mode all the
Well, I should have double checked the PoPS. Even if everybody thought this
was an excellent idea (which they don't), all the current Control Registers
0-15 are in use. So there isn't one available to hold the Register Stack
value. So it would require a special purpose instruction, like SET
CC has made my point better than I did.
For reasons that I have never really understood assembly-language
programmers almost always use heap storage for DSAs instead of the
stack storage they should use. (Their failure to use an extension of
such a stack-based DSA for scratch/automatic/local
As we had been using the stack storage concept since the late 1970's, with a suite of entry, exit, calland DSA macros, it was relatively easy to make all of our assembler programs LE-compliant for our 1998 release. For most assembler programmers, however, the thought of LE seems akin to entering
Wow, exactly. Our code just doesn't jibe with LE and there seems to be no way
around it...
Von: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] Im
Auftrag von David P de Jongh
Gesendet: Donnerstag, 27. Juni 2013 20:56
An:
Well some of us actually do exactly that, and here's the start of a routine
EXECANTL HMSECT ,
HMRDATA DEF
ANTRQTC MF=(L,EXECANTL_ANTRQ) ANTRQST parameter list
EXECANTL_ANTRCD DS F ANTRQST retcode
EXECANTL_ANTRSN DS F ANTRQST reason code
EXECANTL_ANTINF
The issue is completely different and conflicting architectures in our case.
Its basis was written long before LE came along which somehow didn't help make
it easier. In our case. Also maybe that we've had very little need for LE
functions, I guess.
-Ursprüngliche Nachricht-
Von: IBM
On 6/27/2013 12:55 PM, David P de Jongh wrote:
As we had been using the stack storage concept since the late 1970's, with a
suite of entry, exit, call and DSA macros, it was relatively easy to make all of
our assembler programs LE-compliant for our 1998 release. For most assembler
programmers,
I'm currently out of the office..
...and will return to the office on Monday, July 1st.
If you need assistance before then, one of my colleagues may be able to assist.
Feel free to contact them using the @CTO Env Eng - Mainframe distribution list
Thanks,
Bob R
As we had been using the stack storage concept since the late 1970's, with a
suite of entry, exit, call and DSA macros, it was relatively easy to make all
of our assembler programs LE-compliant for our 1998 release. For most
assembler programmers, however, the thought of LE seems akin to
19 matches
Mail list logo
