AW: how to: document usage of bit(s) of a register.
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 14:10 An: ASSEMBLER-LIST@LISTSERV.UGA.EDU Betreff: Re: how to: document usage of bit(s) of a register. Hum. That is a possibility. But why replace 1 instruction with 2? RLLG R0,R13,32 vs. LR R0,R13 SLLG R0,32 RLLG is 6 bytes. LR+SLLG is 2+6==8 bytes. So both sequences end up doing what I want. And, to me, a single 6 byte instruction is better than 2 instructions totaling 8 bytes. Admitted, the difference is moot in most cases. But why not be as efficient as possible, when it is not any harder to code? On Wed, Jun 26, 2013 at 10:32 PM, Robert A. Rosenberg a...@rarpsl.comwrote: At 21:06 -0500 on 06/26/2013, John McKown wrote about Re: how to: document usage of bit(s) of a register.: But, in this code, I did not care what happened to bits 0-31 of R13 or anything in R0. I could not do the simple LR R0,R13 because I use the lower fullword of R0 later in the code. So why not LR R0,R13 followed by a SHIFT LEFT GRANDE 32 Bits of R0 (assuming that there is such a command)? -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown
wish? for two new instructions.
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 machines. 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 which can be dynamically expanded (cause a PIC which the OS, z/OS in my case, would trap and then get a new area and chain it to the old area). The PUSH and POP could only use this stack, which I guess would be pointed to my a CR? So the stack itself could be in key 0 (or maybe other non-key 8/9 storage), AMODE(64) storage. Perhaps LSQA. This would prevent the ever popular (with hackers) stack corruption and overflow condition by normal user code. Why did I bring this up, beyond my usual liking for talk? Mainly because it would help clean up all the problems with the current linkage convention. I.e. what format is the caller's save area? Is there one? Is it big enough to store all the grande registers plus access registers? This latter is important to me because I write code which uses those and I need somewhere to store the caller's. Yes, I guess that I could save the minimal number of registers and do a STORAGE OBTAIN to get the real save area. But then I don't have a way to communicate to the dump format routine where the caller's registers really are. Plus, I would hope that the PUSHR/POPR instruction (assuming no stack over/under flow) would be more CPU efficient than a bunch of STORAGE OBTAIN invocations. And might even make some things easier to code, such as SRB routines. Am I off in la-la land again? Do I need more caffeine? Or less? -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown
Re: how to: document usage of bit(s) of a register.
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 * low order 32 bits of GPR 0. * LRR0,R13 Copy the low order 32 bits * of GPR 13 into the low * order 32 bits of GPR 0. * RLLG R0,R0,32(0) Exchange the high order and * low order 32 bits of GPR 0. * * The high order 32 bits of * GPR 0 now contain a copy of * the low order 32 bits of * GPR 13. * * The low order 32 bits of * GPR 0 are what they were * prior to the first RLLG. Bob
Re: how to: document usage of bit(s) of a register.
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 here. Anyway...) -Ursprüngliche Nachricht- Von: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] Im Auftrag von Bob Raicer Gesendet: Donnerstag, 27. Juni 2013 15:47 An: ASSEMBLER-LIST@LISTSERV.UGA.EDU Betreff: Re: how to: document usage of bit(s) of a register. 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 * low order 32 bits of GPR 0. * LRR0,R13 Copy the low order 32 bits * of GPR 13 into the low * order 32 bits of GPR 0. * RLLG R0,R0,32(0) Exchange the high order and * low order 32 bits of GPR 0. * * The high order 32 bits of * GPR 0 now contain a copy of * the low order 32 bits of * GPR 13. * * The low order 32 bits of * GPR 0 are what they were * prior to the first RLLG. Bob
Re: how to: document usage of bit(s) of a register.
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 inserts the high word of the result into the high word of R0. On Thu, Jun 27, 2013 at 8:44 AM, Steve Smith sasd...@gmail.com wrote: Your problem is documented in the example on page A-30: ROTATE THEN OR SELECTED BITS The following example illustrates the use of ROTATE THEN OR SELECTED BITS to rotate and combine selected bits of general registers 6 and 8. LG 6,=X'004C487040CF4600' LG 8,=X'C07FAF37FC968280' ROSBG 6,8,8,54,32 On completion, condition code 1 is set, and general register 6 is as follows: GR6: 00DECAF0C0FFEE00 Note that only bits 8-54 of the registers are ORed; bits 0-7 and 55-63 of general register 6 are not modified. Correcting this to add caffeine is left as an exercise for anyone who cares to. I'm continually amazed at the instructions the architecture has gotten vs. ones it hasn't. On Thu, Jun 27, 2013 at 8:53 AM, John McKown john.archie.mck...@gmail.comwrote: Missed that. Too early (local time) to be reading tech documents. Waiter! More caffeine!! Hum, I wonder if that makes me a drug addict? -- sas -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown
Re: how to: document usage of bit(s) of a register.
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 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
Re: how to: document usage of bit(s) of a register.
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 emulating a LHLR. Robert Ngan CSC Financial Services Group
Re: wish? for two new instructions.
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 which can be dynamically expanded (cause a PIC which the OS, z/OS in my case, would trap and then get a new area and chain it to the old area). I think that's what z/OS does with the linkage stack. The PUSH and POP could only use this stack, which I guess would be pointed to my a CR? So the stack itself could be in key 0 (or maybe other non-key 8/9 storage), AMODE(64) storage. Perhaps LSQA. AFAICT, the linkage stack is located in ELSQA. Why did I bring this up, beyond my usual liking for talk? Mainly because it would help clean up all the problems with the current linkage convention. I.e. what format is the caller's save area? The called program does not determine the format of the caller's save area. The caller's save area does not have a format until a called program uses it, and it is the caller's responsibility to provide a save area that is suitable for called program to save what it needs to save. The documentation of the linkage conventions in Chapter 2 of the Assembler Services Guide were extensively revised for z/OS release 1.12 to make this clear. Is there one? Is it big enough to store all the grande registers plus access registers? As above, it is the caller's responsibility to provide a save area that is big enough. If it doesn't, something bad will happen. This is really no different than any other requirements that the called program might have, such as the number of parameters passed. The only difference is that the called program has no way to validate the save area before it needs to use it. This latter is important to me because I write code which uses those and I need somewhere to store the caller's. You may be under some of the same misconceptions that I was a few years ago when I asked Peter Relson several questions that led him to revise the Linkage Conventions documentation. You might want to read it again. Yes, I guess that I could save the minimal number of registers and do a STORAGE OBTAIN to get the real save area. You could save your caller's registers in F5SA or F8SA format, depending on whether programs that you call need a 144-byte or a 216-byte save area. Both of these save the low halves if the registers in the caller's 72-byte save area and the high halves in your save area. Then, if necessary, you could save the access registers somewhere else. But then I don't have a way to communicate to the dump format routine where the caller's registers really are. If you are using the access registers and that is your primary concern, your initial entry could use F8SA, then call another entry point that would use F7SA. What dump format routine are you using? Am I off in la-la land again? Do I need more caffeine? Or less? That's not for me to say -- Tom Marchant
Re: wish? for two new instructions.
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 such a condition. BAKR/PC build the Linkage Stack in the 'Home Address Space' so I don't see much difference to your proposed LSQA. The POP says that the Linkage Stack is not modifiable except by the BAKR, PC, PR,and MSTA. So I not sure about the 'HACKER' comment. 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.
Re: wish? for two new instructions.
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 time. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/
Re: wish? for two new instructions.
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 PREFIX, to set the stack pointer. I was warned about using BAKR/PC in a CICS assembler routine if there was any chance of a program check. There is. But why is is not relevant to this discussion, and I don't want a us to veer off course like we do on IBM-MAIN quite often. Suffice it to say that it would be too difficult for something will too little return at this late date. On Thu, Jun 27, 2013 at 12:00 PM, Chris Craddock crash...@hotmail.comwrote: Not to take issue with JG on this but stacking operations definitely store a lot more machine state than normal program linkage would require and so even on the most current machines they take a lot longer. It would be a bad idea to do wholesale replacement of traditional entry/exit linkage with BAKR/PR. But we're talking in terms of microseconds per instruction. The stacking instructions are enormously valuable in situations where the alternative would require you to obtain storage. They will ALWAYS outperform OS storage obtain/release by many orders of magnitude. So use them appropriately for your situation and there's no real down side. At this point I would usually feel compelled to throw in a remark about interactions with recovery. But I am on a phone, so I won't. CC On Jun 27, 2013, at 9:37 AM, John Gilmore jwgli...@gmail.com wrote: I wish I had some definitive timing results to provide. I do not. I can, however, report that timings for otherwise identical blocks of SRB code within which BAKR/PR and alternatives to them are used do not at all support the notion that BAKR/PR is slower than they. John Gilmore, Ashland, MA 01721 - USA -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown
Re: wish? for two new instructions.
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 storage is a little, but only a little, more excusable.) John Gilmore, Ashland, MA 01721 - USA
Re: wish? for two new instructions.
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 the den of the basilisk.David de JonghOn 06/27/13, John Gilmorejwgli...@gmail.com wrote:CC has made my point better than I did.For reasons that I have never really understood assembly-languageprogrammers almost always use heap storage for DSAs instead of thestack storage they should use. (Their failure to use an extension ofsuch a stack-based DSA for scratch/automatic/local storage is alittle, but only a little, more excusable.)John Gilmore, Ashland, MA 01721 - USA
AW: wish? for two new instructions.
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: ASSEMBLER-LIST@LISTSERV.UGA.EDU Betreff: Re: wish? for two new instructions. 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 entering the den of the basilisk. David de Jongh On 06/27/13, John Gilmorejwgli...@gmail.com wrote: 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 storage is a little, but only a little, more excusable.) John Gilmore, Ashland, MA 01721 - USA
AW: wish? for two new instructions.
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 DS F,XL96 ANTRQST retinfo * HMRDATA HMERH ADD,EXIT=EXECANTL_ABND,PRXO=(IDMP,IABM) The HMRDATA macros declare the dynamic storage local to the code section (plus SA, recovery data etc). All allocated up in a stack set up at program entry. Sorry about the capitals though, no one's perfect. -Ursprüngliche Nachricht- Von: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] Im Auftrag von John Gilmore Gesendet: Donnerstag, 27. Juni 2013 19:28 An: ASSEMBLER-LIST@LISTSERV.UGA.EDU Betreff: Re: wish? for two new instructions. 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 storage is a little, but only a little, more excusable.) John Gilmore, Ashland, MA 01721 - USA
Re: wish? for two new instructions.
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 Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] Im Auftrag von Steve Comstock Gesendet: Donnerstag, 27. Juni 2013 21:12 An: ASSEMBLER-LIST@LISTSERV.UGA.EDU Betreff: Re: wish? for two new instructions. 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, however, the thought of LE seems akin to entering the den of the basilisk. We can fix that: Using LE Services in z/OS - 3 days - includes coding LE-conforming assembler programs http://www.trainersfriend.com/Language_Environment_courses/m512descr.htm But, of course, it takes management direction to take that path. -Steve Comstock David de Jongh On 06/27/13, John Gilmorejwgli...@gmail.com wrote: 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 storage is a little, but only a little, more excusable.) John Gilmore, Ashland, MA 01721 - USA
Re: wish? for two new instructions.
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, however, the thought of LE seems akin to entering the den of the basilisk. We can fix that: Using LE Services in z/OS - 3 days - includes coding LE-conforming assembler programs http://www.trainersfriend.com/Language_Environment_courses/m512descr.htm But, of course, it takes management direction to take that path. -Steve Comstock David de Jongh On 06/27/13, John Gilmorejwgli...@gmail.com wrote: 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 storage is a little, but only a little, more excusable.) John Gilmore, Ashland, MA 01721 - USA
Automatic reply: ASSEMBLER-LIST Digest - 26 Jun 2013 to 27 Jun 2013 (#2013-92)
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 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
Re: wish? for two new instructions.
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 entering the den of the basilisk. David de Jongh Almost all the assembler code I write is ‘just’ application code (as opposed to system exits, PC routines or whatever). It’s used in applications written in COBOL or PL/I. All of the assembler code is LE compliant (the LE entry and exit macros are used and R12 is reserved for the CAA) and I think this is actually an advantage: the entry and exit macros are very fast especially compared to alternatives where you must allocate a save area in every invocation. We also use LE heap storage whenever we need dynamic storage in the application. Fine as long as you don’t need to do special things like sharing memory between (instances of) applications and much faster than the STORAGE functions. I don’t understand the reluctance towards LE in this particular scenario… Fred! - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. -
