Re: z/Architecture Principles of Operation (SA22-7832-04)
A danger of using the IEABRC approach for the long-displacement instructions is that the size of the instructions differ between the regular and the long displacement. That might not matter to a given module but could cause some unexpected difficulties with macro expansions that might have an operand something like *+n, taking advantage of knowing how long the current instruction is. We felt fully comfortable with IEABRC because all of the relative-branch instructions were of the same length as their base-displacement equivalents. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
Peter Relson wrote: A danger of using the IEABRC approach for the long-displacement instructions is that the size of the instructions differ between the regular and the long displacement. That might not matter to a given module but could cause some unexpected difficulties with macro expansions that might have an operand something like *+n, taking advantage of knowing how long the current instruction is. That's a good point! And currently there's no SYSSTATE setting that can be used to toggle whether LD instructions are available -- therefore, no way for the macros to know they should/can expand differently. Guess we're SOL until the next level set unless you can think of a good workaround. :-( -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
At 08:29 -0600 on 02/20/2006, Todd Burch wrote about Re: z/Architecture Principles of Operation (SA22-7832-04): Roland, it's not that the IBM DSECTs are 4096, it's that mine is. And, for instance, the MF=(E,WORKOPEN) execute form of the macro was in storage 12 bits away. I seem to remember that the address of a MF=E can take a register. Why not preload the register that MF=E loads (R1 I think) via a LAY and go MF=(E,(1))? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
Certainly I can do that. And, when I do that, I have absolutely no need for the LDF instructions. The purpose of the Long Displacement Facility is to provide relief for base register constraint. Coding a LAY R1 to get around a macro expansion, and taking up a base register to do that, doesn't buy me diddly squat in terms of base register relief. Todd - Original Message - From: Robert A. Rosenberg [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Tuesday, February 21, 2006 11:23 AM Subject: Re: z/Architecture Principles of Operation (SA22-7832-04) At 08:29 -0600 on 02/20/2006, Todd Burch wrote about Re: z/Architecture Principles of Operation (SA22-7832-04): Roland, it's not that the IBM DSECTs are 4096, it's that mine is. And, for instance, the MF=(E,WORKOPEN) execute form of the macro was in storage 12 bits away. I seem to remember that the address of a MF=E can take a register. Why not preload the register that MF=E loads (R1 I think) via a LAY and go MF=(E,(1))? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
Just curious, what is diddly squat selling for these days? [EMAIL PROTECTED] 2/21/2006 12:51 PM Certainly I can do that. And, when I do that, I have absolutely no need for the LDF instructions. The purpose of the Long Displacement Facility is to provide relief for base register constraint. Coding a LAY R1 to get around a macro expansion, and taking up a base register to do that, doesn't buy me diddly squat in terms of base register relief. Todd - Original Message - From: Robert A. Rosenberg [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Tuesday, February 21, 2006 11:23 AM Subject: Re: z/Architecture Principles of Operation (SA22-7832-04) At 08:29 -0600 on 02/20/2006, Todd Burch wrote about Re: z/Architecture Principles of Operation (SA22-7832-04): Roland, it's not that the IBM DSECTs are 4096, it's that mine is. And, for instance, the MF=(E,WORKOPEN) execute form of the macro was in storage 12 bits away. I seem to remember that the address of a MF=E can take a register. Why not preload the register that MF=E loads (R1 I think) via a LAY and go MF=(E,(1))? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
Steve Comstock wrote: What LDF gives is relief in tying up base registers for branches, nothing more. You don't have to have a base established for your target address. You still need a register to move, store, and load data in memory. Whaaatt???!!! LDF has _nothing whatsoever_ to do with branches!!! You're thinking of the immediate relative facility, which was around long before z/Architecture. I suggest a perusal of Principles of Operation may be in order ... -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
Just curious, what is diddly squat selling for these days? I would have thought for about $0.02 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
At 11:51 -0600 on 02/21/2006, Todd Burch wrote about Re: z/Architecture Principles of Operation (SA22-7832-04): Certainly I can do that. And, when I do that, I have absolutely no need for the LDF instructions. The purpose of the Long Displacement Facility is to provide relief for base register constraint. Coding a LAY R1 to get around a macro expansion, and taking up a base register to do that, doesn't buy me diddly squat in terms of base register relief. R1 IS the register that is loaded by the MF=(E,LIST) parm. Thus loading it via a LAY and coding MF=(E,(1)) tells the Macro to not generate the LA 1,List (since R1 has already been loaded). There is no EXTRA register used. Here are the expansions for your review. 000 00014 1 TESTMF CSECT R:C 0 2 USING *,12 3 WTO MF=(E,LIST) 00 4110 C01000010 7+ LA1,LIST 04 0A23 8+ SVC 35 06 E310 C010 0071 00010 9 LAY 1,LIST 10 WTO MF=(E,(1)) 0C 0A23 14+ SVC 35 10 15 LIST DSF 16 END -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
But you do need to change all macros which generate in-line branches not to do so. A macro usually needs to use the MF=L/MF=E pair to avoid the generated branch. Some need more. IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 02/21/2006 01:32:55 PM: What LDF gives is relief in tying up base registers for branches, nothing more. You don't have to have a base established for your target address. You still need a register to move, store, and load data in memory. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
At 13:57 -0600 on 02/21/2006, Todd Burch wrote about Re: z/Architecture Principles of Operation (SA22-7832-04): Point taken, and I have to agree that your sample coding technique will work just fine. However, I prefer to let the assembler work for me, and to not spend my time manually coding up all the parms and bits and such for macros, so that when they expand all that is left to expand is an SVC. Todd The sample I supplied was just to show the MF expansion (which was what you were complaining about). The rest of the Macro Parms would be coded normally. OTOH, so long as you are trying to go with baseless coding, you have to worry about the macros that need base registers for their expansion/parameter-references. - Original Message - From: Robert A. Rosenberg [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Tuesday, February 21, 2006 1:40 PM Subject: Re: z/Architecture Principles of Operation (SA22-7832-04) At 11:51 -0600 on 02/21/2006, Todd Burch wrote about Re: z/Architecture Principles of Operation (SA22-7832-04): Certainly I can do that. And, when I do that, I have absolutely no need for the LDF instructions. The purpose of the Long Displacement Facility is to provide relief for base register constraint. Coding a LAY R1 to get around a macro expansion, and taking up a base register to do that, doesn't buy me diddly squat in terms of base register relief. R1 IS the register that is loaded by the MF=(E,LIST) parm. Thus loading it via a LAY and coding MF=(E,(1)) tells the Macro to not generate the LA 1,List (since R1 has already been loaded). There is no EXTRA register used. Here are the expansions for your review. 000 00014 1 TESTMF CSECT R:C 0 2 USING *,12 3 WTO MF=(E,LIST) 00 4110 C01000010 7+ LA1,LIST 04 0A23 8+ SVC 35 06 E310 C010 0071 00010 9 LAY 1,LIST 10 WTO MF=(E,(1)) 0C 0A23 14+ SVC 35 10 15 LIST DSF 16 END -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
Robert A. Rosenberg wrote: At 11:51 -0600 on 02/21/2006, Todd Burch wrote about Re: z/Architecture Principles of Operation (SA22-7832-04): Certainly I can do that. And, when I do that, I have absolutely no need for the LDF instructions. The purpose of the Long Displacement Facility is to provide relief for base register constraint. Coding a LAY R1 to get around a macro expansion, and taking up a base register to do that, doesn't buy me diddly squat in terms of base register relief. R1 IS the register that is loaded by the MF=(E,LIST) parm. Thus loading it via a LAY and coding MF=(E,(1)) tells the Macro to not generate the LA 1,List (since R1 has already been loaded). There is no EXTRA register used. Here are the expansions for your review. 000 00014 1 TESTMF CSECT R:C 0 2 USING *,12 3 WTO MF=(E,LIST) 00 4110 C01000010 7+ LA1,LIST 04 0A23 8+ SVC 35 06 E310 C010 0071 00010 9 LAY 1,LIST 10 WTO MF=(E,(1)) 0C 0A23 14+ SVC 35 10 15 LIST DSF 16 END This works only for very simplistic cases. Many modern interfaces have numerous parameters that are access by the macro via LA instructions or moved directly to/from the parameter list using the MVC instruction. For example: |005C 59 MVC PLIST(LOGRGBRML),LOGRGBRM Copy model IXGBRWSE prm list |** ASMA034E Operand PLIST(LOGRGBRML) beyond active USING range by 363 bytes |** ASMA435I Record 0 in EDJX2.TESTSCH.J0076849.D101.? on volume: | 60 IXGBRWSE REQUEST=READCURSOR, | DIRECTION=YOUNGTOOLD, | RETBLOCKID=BLOCKID, |BUFFER=(4), | BUFFLEN=BUFLEN, | BLKSIZE=BLKSIZE, | STREAMTOKEN=STRMTOK, | BROWSETOKEN=BRWSTOK, | TIMESTAMP=STAMP, | MODE=SYNCECB, |ECB=MYECB, | ANSAREA=ANSAREA, | ANSLEN=ANSLEN, | MF=(E,PLIST) | 61+* MACDATE -03/06/16-3 |0062 62+M00M0004 DS 0H IXGBRWSE-3 | 63+ PUSH PRINT | 64+ PRINT ON |0062 65+ LA 1,PLIST++ LOCATE ARG PARMS |** ASMA034E Operand PLIST beyond active USING range by 363 bytes |** ASMA435I Record 9569 in SYS1.MACLIB(IXGBRWSE) on volume: |0066 D75B 1000 1000 66+ XC 0(92,1),0(1) ++ INITIALIZE |006C 9202 1001 0001 67+ MVI 1(1),2 ++ INPUT XREQUEST |0070 D601 1002 C168 0002 0168 68+ OC 2(2,1),=BL2'1000' ++ INPUT BL2 |0076 5040 1008 0008 69+ ST 4,8(,1)++ INPUT XBUFFER |007A 70+ MVC 16(4,1),BUFLEN ++ INPUT XBUFFLEN |** ASMA034E Operand BUFLEN beyond active USING range by 633 bytes |** ASMA435I Record 9569 in SYS1.MACLIB(IXGBRWSE) on volume: |0080 71+ LA 14,BLKSIZE ++ INPUT XBLKSIZE |** ASMA034E Operand BLKSIZE beyond active USING range by 637 bytes |** ASMA435I Record 9569 in SYS1.MACLIB(IXGBRWSE) on volume: |0084 50E0 1018 0018 72+ ST 14,24(,1) ++ INPUT XBLKSIZE |0088 73+ LA 14,MYECB ++ INPUT XECB |** ASMA034E Operand MYECB beyond active USING range by 665 bytes |** ASMA435I Record 9569 in SYS1.MACLIB(IXGBRWSE) on volume: |008C 50E0 101C 001C 74+ ST 14,28(,1) ++ INPUT XECB |0090 75+ LA
Re: z/Architecture Principles of Operation (SA22-7832-04)
Chris, yes, my perspective is different than yours. Mine is for serviceable, well documented code (I'm absolutely NOT implying that your's isn't). There are several folks in my department and we all service all the code. There's no value in being criptic or concise to the point that you have to be a 40 year veteran of assembler coding to service a module. (I've only been coding since '86...) Today, I would argue there this a huge need to know the macros, and not the expansions. Tie yourself to manually coding the plists and now you've entered doubt and uncertainty, and a service-point-check when migrating to new macro libs with new operating systems and new hardware. Does IBM say protect your investment? Yes, and that's a good thing. :) Todd - Original Message - From: Chris Mason [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Tuesday, February 21, 2006 2:54 PM Subject: Re: z/Architecture Principles of Operation (SA22-7832-04) Todd, My assembler-writing days started in 1967 when storage was not all that abundant and economy was paramount*. Concise coding became an ingrained habit and I was often upset by inefficient macro expansions. Thus I preferred, for example, to manipulate my register usage to fit what I knew was needed by the coming macro expansion. Finally, there was really no need for the macro at all - except to document the SVC call - just like WTO MF=(E,(1)) for SVC 35 below now I take a look at it. So I guess that's the diametric opposite of your approach :-) * I was once on the edge of a project to create some spooling code for DOS - that's the VSE of today. The target was 4K since it was designed to be able to fit into a 32K - 64K if you were rich - System 360 Model 30 or 40. One suggestion from the review panel was to use the X'1A' of - I think - the AR instruction in place of a packed decimal 1 constant. Chris Mason -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
Tell me about it Ed.I forget how many assembly errors I got the first time I attemped: MVCY TRTY UNPKY, etc. Too bad. Roland, it's not that the IBM DSECTs are 4096, it's that mine is. And, for instance, the MF=(E,WORKOPEN) execute form of the macro was in storage 12 bits away. The IEABRC method is a good idea. I hadn't thought of that. Not sure I would want to write or maintain one to convert to the Y formats myself though. I wouldn't want to test it either. Todd - Original Message - From: Edward E. Jaffe [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Monday, February 20, 2006 1:09 AM Subject: Re: z/Architecture Principles of Operation (SA22-7832-04) Schiradin,Roland HG-Dir itb-db/dc wrote: Haven't seen any IBM-DSECT which is longer then 4096 bytes (z/os R4 and R7) Or do you think about you own DSECT for working storage or static areas? Perhaps you can substitude the instruction like COPY IEABRC does? Oh well haven't spend so much time to look at it. You may post this to the Assembler listserver. Not a bad idea. Could work in many cases, but probably not all. :-( The long displacement facility adds the RSY, RXY, and SIY instruction formats. Unfortunately, there are no equivalents for any of the SS format instructions, probably because such instructions would require a heretofore unsupported eight-byte instruction format. This restriction means that extremely popular instructions like XC, MVC, etc. have no long displacement counterparts... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
(Attn: old post resurrection warning...) Thomas, I'm using the Long Displacement Facility quite a bit in a piece of code I'm writing now. It's not so much that I need it for the CSECT, but for the DSECT. Overall, I'm pretty satisfied with it. There is however, one consideration that I'll point out. There is no way to tell (that I have figured out) IBM macros to expand and exploit this facility. Any operands to fields that are past 4096 bytes of your closest USING do not assemble properly. (Examples, OPEN, GET) So, for big sections, you still need to have a register available for addressing around these macros. Todd FYI: How to test for this facility: USING PSA,0 TMFLCEFACILITIESBYTE2,X'20' BNO NOT_INSTALLED LONG DISPLACEMENT FACILITY NOT INSTALLED DROP 0 ... IHAPSA LIST=YES END On Wed, 21 Sep 2005 05:57:53 +0200, Thomas Berg [EMAIL PROTECTED] wrote: Thanks, was it any problems regarding certain instructions/operations and if so, had you some interestion solutions for them ? TIA Thomas Berg == Tom Harper == wrote2005-09-21 05:41: Thomas, We have used the long-displacement instructions to allow for the generation of additional compiled code over the short-displacement instructions, if the machine environment supports them, removing the old size limitations of +/- 64K. It was really not all that difficult to implement (baseless code generation). We have actually converted most of our critical-path instruction sequences to baseless code, believing future machines will execute these instructions faster, due to fewer base-register interlocks. This was fairly straight-foward using the structured programming facilities of HLASM. Tom Harper From: IBM Mainframe Discussion List on behalf of Thomas Berg Sent: Tue 9/20/2005 9:10 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: z/Architecture Principles of Operation (SA22-7832-04) Have anyone used the long-displacement facility instructions (as in consistently do so to reduce base register usage) ? Are there any pitfalls or limitations that a relatively inexperienced programmer should be aware of ? Btw, why is there no MVCY instruction ? Is it because of the existence of the MVCL instruction or .. ? TIA Thomas Berg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
Haven't seen any IBM-DSECT which is longer then 4096 bytes (z/os R4 and R7) Or do you think about you own DSECT for working storage or static areas? Perhaps you can substitude the instruction like COPY IEABRC does? Oh well haven't spend so much time to look at it. You may post this to the Assembler listserver. Roland -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Todd Burch Sent: Sunday, February 19, 2006 8:01 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: z/Architecture Principles of Operation (SA22-7832-04) (Attn: old post resurrection warning...) Thomas, I'm using the Long Displacement Facility quite a bit in a piece of code I'm writing now. It's not so much that I need it for the CSECT, but for the DSECT. Overall, I'm pretty satisfied with it. There is however, one consideration that I'll point out. There is no way to tell (that I have figured out) IBM macros to expand and exploit this facility. Any operands to fields that are past 4096 bytes of your closest USING do not assemble properly. (Examples, OPEN, GET) So, for big sections, you still need to have a register available for addressing around these macros. Todd FYI: How to test for this facility: USING PSA,0 TMFLCEFACILITIESBYTE2,X'20' BNO NOT_INSTALLED LONG DISPLACEMENT FACILITY NOT INSTALLED DROP 0 ... IHAPSA LIST=YES END -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
Schiradin,Roland HG-Dir itb-db/dc wrote: Haven't seen any IBM-DSECT which is longer then 4096 bytes (z/os R4 and R7) Or do you think about you own DSECT for working storage or static areas? Perhaps you can substitude the instruction like COPY IEABRC does? Oh well haven't spend so much time to look at it. You may post this to the Assembler listserver. Not a bad idea. Could work in many cases, but probably not all. :-( The long displacement facility adds the RSY, RXY, and SIY instruction formats. Unfortunately, there are no equivalents for any of the SS format instructions, probably because such instructions would require a heretofore unsupported eight-byte instruction format. This restriction means that extremely popular instructions like XC, MVC, etc. have no long displacement counterparts... -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
Thomas, No problems whatsoever... Tom Harper From: IBM Mainframe Discussion List on behalf of Thomas Berg Sent: Tue 9/20/2005 10:57 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: z/Architecture Principles of Operation (SA22-7832-04) Thanks, was it any problems regarding certain instructions/operations and if so, had you some interestion solutions for them ? TIA Thomas Berg == Tom Harper == wrote2005-09-21 05:41: Thomas, We have used the long-displacement instructions to allow for the generation of additional compiled code over the short-displacement instructions, if the machine environment supports them, removing the old size limitations of +/- 64K. It was really not all that difficult to implement (baseless code generation). We have actually converted most of our critical-path instruction sequences to baseless code, believing future machines will execute these instructions faster, due to fewer base-register interlocks. This was fairly straight-foward using the structured programming facilities of HLASM. Tom Harper -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
z/Architecture Principles of Operation (SA22-7832-04)
The subject document is published. It may be accessed on the IBM web site at the following URL: http://publibz.boulder.ibm.com/epubs/pdf/a2278324.pdf Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
Jim Mulder wrote: The subject document is published. It may be accessed on the IBM web site at the following URL: http://publibz.boulder.ibm.com/epubs/pdf/a2278324.pdf Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY Great! Thanks, Jim. Kind regards, -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
Jim, you posted at 1:59. Apparently by 2:10, most of the IBM-MAIN list was downloading it. It took me about 5 minutes, which is exceptionally long. But it is much appreciated. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
Have anyone used the long-displacement facility instructions (as in consistently do so to reduce base register usage) ? Are there any pitfalls or limitations that a relatively inexperienced programmer should be aware of ? Btw, why is there no MVCY instruction ? Is it because of the existence of the MVCL instruction or .. ? TIA Thomas Berg == Jim Mulder == wrote2005-09-20 19:59: The subject document is published. It may be accessed on the IBM web site at the following URL: http://publibz.boulder.ibm.com/epubs/pdf/a2278324.pdf Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- -- Mundus Vult Decipi -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
On Wed, 21 Sep 2005 04:10:47 +0200, Thomas Berg wrote:
Have anyone used the long-displacement facility instructions
(as in consistently do so to reduce base register usage) ?
Are there any pitfalls or limitations that a relatively
inexperienced programmer should be aware of ?
Btw, why is there no MVCY instruction ? Is it because of
the existence of the MVCL instruction or .. ?
Not consistently yet, no. (There were a few gaps - at least until the new
PoP z9 offered more toys to play with.) What I have used seemed to all
work as advertised.
Don't feel bad about MVCY being missing; Ed is still holding a torch for
EXR (relative execute) and I'm kind of hoping for EXRG as a register-only
Execute Grande (EXR R1,R2 with R1 R2 being 64-bit registers so that
every bit that's on ('1'b) in R1 gets OR-ed over the first (up to) 64-bits
at the R2 target instruction address (in millicode workspace or
similar)). I see that as the ultimate execute. (Motto: 64-bits while
you wait!) They could make it up to 64-bits depending on the opcode or
they could just say 'caveat emptor' at let you swing away at it. (I'm all
for the second choice myself.)
(Someone should warn the architects not to be drinking hot liquids while
they read this post.)
--
Tom Schmidt
Madison, WI
(Maybe it would be more like 'caveat empty'?)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
Ah, yes, how to get an opcode and two Y-format operands into a single 6-byte instruction :) Thomas Berg wrote: Have anyone used the long-displacement facility instructions (as in consistently do so to reduce base register usage) ? Are there any pitfalls or limitations that a relatively inexperienced programmer should be aware of ? Btw, why is there no MVCY instruction ? Is it because of the existence of the MVCL instruction or .. ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
Thomas, We have used the long-displacement instructions to allow for the generation of additional compiled code over the short-displacement instructions, if the machine environment supports them, removing the old size limitations of +/- 64K. It was really not all that difficult to implement (baseless code generation). We have actually converted most of our critical-path instruction sequences to baseless code, believing future machines will execute these instructions faster, due to fewer base-register interlocks. This was fairly straight-foward using the structured programming facilities of HLASM. Tom Harper From: IBM Mainframe Discussion List on behalf of Thomas Berg Sent: Tue 9/20/2005 9:10 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: z/Architecture Principles of Operation (SA22-7832-04) Have anyone used the long-displacement facility instructions (as in consistently do so to reduce base register usage) ? Are there any pitfalls or limitations that a relatively inexperienced programmer should be aware of ? Btw, why is there no MVCY instruction ? Is it because of the existence of the MVCL instruction or .. ? TIA Thomas Berg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
Well, the implementation problem is not mine... :) And whats wrong with 8 bytes instructions in these 64-bits days... :) == Greg Price == wrote2005-09-21 05:01: Ah, yes, how to get an opcode and two Y-format operands into a single 6-byte instruction :) Thomas Berg wrote: Have anyone used the long-displacement facility instructions (as in consistently do so to reduce base register usage) ? Are there any pitfalls or limitations that a relatively inexperienced programmer should be aware of ? Btw, why is there no MVCY instruction ? Is it because of the existence of the MVCL instruction or .. ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- -- Mundus Vult Decipi -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture Principles of Operation (SA22-7832-04)
Thanks, was it any problems regarding certain instructions/operations and if so, had you some interestion solutions for them ? TIA Thomas Berg == Tom Harper == wrote2005-09-21 05:41: Thomas, We have used the long-displacement instructions to allow for the generation of additional compiled code over the short-displacement instructions, if the machine environment supports them, removing the old size limitations of +/- 64K. It was really not all that difficult to implement (baseless code generation). We have actually converted most of our critical-path instruction sequences to baseless code, believing future machines will execute these instructions faster, due to fewer base-register interlocks. This was fairly straight-foward using the structured programming facilities of HLASM. Tom Harper From: IBM Mainframe Discussion List on behalf of Thomas Berg Sent: Tue 9/20/2005 9:10 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: z/Architecture Principles of Operation (SA22-7832-04) Have anyone used the long-displacement facility instructions (as in consistently do so to reduce base register usage) ? Are there any pitfalls or limitations that a relatively inexperienced programmer should be aware of ? Btw, why is there no MVCY instruction ? Is it because of the existence of the MVCL instruction or .. ? TIA Thomas Berg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- -- Mundus Vult Decipi -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
