Re: Eliminating Base Registers (was: Inlining routines)
I much prefer having eyecatchers show up in save area tracebacks, even if that "wastes" space. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Martin Trübner [mar...@pi-sysprog.de] Sent: Saturday, April 2, 2022 12:55 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Eliminating Base Registers (was: Inlining routines) Charles (et al), I like the entry being at the CSECT and the base pointing to the entry of the CSECT (and I am lazy) so I borrowed a neat technique from Ed Jaffe I marked it with "<--- this is new " in your sample It costs only 4bytes and helps me. TEST CSECT MAIN1LOCTR J MYENTRY <- this is new M1 DC'Eyecatcher at front of CSECT' MAIN2LOCTR DSHalignment MYENTRY EQU * ENTRY MYENTRY<- this is superfloush now SAVE ... LARL R12,TEST no more BALRs! USING TEST,R12 code ... MAIN1LOCTR * put any macros that need a base in little subroutines here LTORG Small constants and, if CSECT not relocatable, work areas MAIN2LOCTR Any large buffers or tables END Martin
Re: Eliminating Base Registers
"Pro" ¬= "hacker". Obfuscated code contests are for amusement, not for production code. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Martin Ward [mar...@gkc.org.uk] Sent: Saturday, April 2, 2022 1:21 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Eliminating Base Registers On 01/04/2022 23:01, Bernd Oppolzer wrote:> where some people without much knowlegde simply used 3, 4 or 5 base > registers to covers the whole program, no matter if it consisted of > code sections, data areas or subroutines. Of course, they ran out of > registers. Amateurs :-) Here is a line of code from a production system (I won't say whose): USING *,2,3,4,5,6,7,8,9,10 That's how the "pros" do it! -- Martin Dr Martin Ward | Email: mar...@gkc.org.uk | http://secure-web.cisco.com/1FnLD_COmPH3TqLPOvQfTHQkITsbKQCFDRXrlglDpqrjgR1LBNcixvOfW7z6VvBlo_pV9VPMx6gc_KTbudNvg6jmIVG9J87ia-4WFZsXr7ecOWtCDCWouZ7l1vcnTOVnrmcoCd6b5ZXKJt5wOe-nWFplUdE7nVyA-sGagvelq06sFFVtb03u-e73W3lU0oKzIECk1SAIpBZl4vs7526lQYVALTz-PFNeOEVYNm8YN0Pm-1UoXeQmd8aflHLxFdZRiCZaXQ-aXWBlDxY27zsbCW5dg7ImlI5ZJ9KAFMrErx2cqgcjD7iQTDn_Pf-9reqVktFg2y6-cX3sPwpZ5x225dY78Y8CvAHsZPc-Eqs5tdczv2lgR-qh1AOIBowfp2InU1n6uBVsmOmZwVLuIKGNKvUChPHO26sUI_fbjcrcE8fin1n_gPtrgnGEIvmMdQ9xx/http%3A%2F%2Fwww.gkc.org.uk G.K.Chesterton site: http://secure-web.cisco.com/1BcBaChq4fuI4R0ONdKp8CldkG5UExYyE5OUaQ6jUY3WBGGBUWfo7yIy0kqEK-VEXh4txpxlhuO4qgvtnu3IAay6gC4pK0wSjRcqup9UK9h7T_9KzffnCZLbBFeLilfEDBYTXNiw_b99U0eFMgQvCZCI7AQ3kXOnXD3DY5pn8YugIH6UsJQPEzoiYpd8jVmrHAh6thx3XymTGBfHRBdLtVpJF04Npu7tBhzdOsHFYbWcv1lSwhsT-AZ9XKNZIRrSPKsbNG7dKKJYmqv0rfCR4BEvdZJNricPDlQvpI1BoMAok7omo8HGl--WlddpGFpFzYeTMzUJ0AUaURAn9Sn9Vr7Dmtu4mB_K8_Hp7LDqj2lgxg4mZr4_fPZ2M09aAlRJLtUC83w9FQInm0dF9se-_H7h9k9zELjztDVVBTldw48qZ2mHCbF7lQyfFMRhn1gRd/http%3A%2F%2Fwww.gkc.org.uk%2Fgkc | Erdos number: 4
Re: Eliminating Base Registers (was: Inlining routines)
Thanks. When I started programming in ASSEMBLER (and teaching) in the mid 1980s, I didn't think much about base registers in the beginning. I also used one base register when starting the mainline, and I used BAL R5,SUBR and BR R5 to manage my internal subroutines. This worked OK for me. This changed dramatically, when I was in charge starting from 1988 in a big insurance company with a large ASSEMBLER code base. The programs there had typical sizes of 20.000 lines and more, they used SP macros (structured programming) and many site-spezific special purpose macros and they had macros to organize the internal subroutines, where the internal subs created their own base registers. The module sizes were large, most of the time more than 16 times 4k. The typical module layout is as follows: Mainline CSECT ... covered by two base regs (for example 13 and 12) LTORG Mainline Static Data First Subroutine ... covered by two base regs (for example 10 and 11) LTORG First Subroutine local Static Data Second Subroutine ... covered by two base regs (again 10 and 11) LTORG Second Subroutine local Static Data .. and so on You may notice, that 4 registers are sufficient to create very large programs. Register 13 is used as base register for the mainline AND for the local save area. There are variants of this scheme: - maybe you don't need two base regs on the subroutines - maybe your program must be RENT, then the startup macro builts a DSECT where all the automatic data is collected, and the startup macro allocates dynamic space for it. In this case, of course, reg 13 cannot be used as base register for the static save area, because it must point to the beginning of the automatic area in the RENT case. In 2013, I was in charge of maintaining the macro library of this insurance company, and I changed the macros to support code sections without base registers. The module in this case looks much the same as above, but the base registers now don't point to the beginning of the CSECT and subroutines, but rather to the end. The code sections are not covered with base registers, and the B instructions are changed to J instructions using the well-known IBM mechanisms (this is MVS, BTW). In the "lucky" case, a change of parameters in the startup macro and a simple recompile is sufficient to convert a program to baseless. But in reality, this is rare, because most of the time there are some inline definitions in some macros which need additional work. Since mid 2021, I am again in charge for the macro library :-) after a 6 year intermission. The company lost a lot of old folks with good ASSEMBLER knowledge by retirement. My work here will hopefully last until 2026, when the company plans to finally migrate the applications to other platforms. HTH, kind regards Bernd Am 02.04.2022 um 18:25 schrieb Charles Mills: A couple of things. One, yes, my assertion that it is easy was based on my own experience primarily with modest-sized programs that I had written myself -- in some cases years earlier. If you are talking about 10,000 lines of spaghetti enhanced over the years by lots of folks, with embedded local macros and various cleverness, then it could be a large and fraught project. ... b. I think all of my programs use a code base register. One code base register. One. I am advocating for (i) getting rid of "4K anxiety" and (ii) freeing up a register or two in those old programs with two or three code base registers.
Re: Eliminating Base Registers (was: Inlining routines)
No argument from me. Diff'rent strokes for diff'rent folks. I don't "mind" having the entry point being in the middle of the CSECT, but if you do ... If someone is using an entry point macro like EDCPRLG you would have to put *it* at the front of the CSECT and put J MYCODE right after it. A lot of my modules are collections of little MVS services for use by REXX or C++ code, so I have lots of modules with multiple entry points. Some of them are inevitably in the middle of the CSECT, whether I like it or not. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Martin Trübner Sent: Saturday, April 2, 2022 9:56 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Eliminating Base Registers (was: Inlining routines) Charles (et al), I like the entry being at the CSECT and the base pointing to the entry of the CSECT (and I am lazy) so I borrowed a neat technique from Ed Jaffe I marked it with "<--- this is new " in your sample It costs only 4bytes and helps me. TEST CSECT MAIN1LOCTR J MYENTRY <- this is new M1 DC'Eyecatcher at front of CSECT' MAIN2LOCTR DSHalignment MYENTRY EQU * ENTRY MYENTRY<- this is superfloush now SAVE ... LARL R12,TEST no more BALRs! USING TEST,R12 code ... MAIN1LOCTR * put any macros that need a base in little subroutines here LTORG Small constants and, if CSECT not relocatable, work areas MAIN2LOCTR Any large buffers or tables END Martin
Re: Eliminating Base Registers
On 01/04/2022 23:01, Bernd Oppolzer wrote:> where some people without much knowlegde simply used 3, 4 or 5 base registers to covers the whole program, no matter if it consisted of code sections, data areas or subroutines. Of course, they ran out of registers. Amateurs :-) Here is a line of code from a production system (I won't say whose): USING *,2,3,4,5,6,7,8,9,10 That's how the "pros" do it! -- Martin Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
Re: Eliminating Base Registers (was: Inlining routines)
Charles (et al), I like the entry being at the CSECT and the base pointing to the entry of the CSECT (and I am lazy) so I borrowed a neat technique from Ed Jaffe I marked it with "<--- this is new " in your sample It costs only 4bytes and helps me. TEST CSECT MAIN1LOCTR J MYENTRY <- this is new M1 DC'Eyecatcher at front of CSECT' MAIN2LOCTR DSHalignment MYENTRY EQU * ENTRY MYENTRY<- this is superfloush now SAVE ... LARL R12,TEST no more BALRs! USING TEST,R12 code ... MAIN1LOCTR * put any macros that need a base in little subroutines here LTORG Small constants and, if CSECT not relocatable, work areas MAIN2LOCTR Any large buffers or tables END Martin
Re: Eliminating Base Registers (was: Inlining routines)
Should be LARL R12,TEST no more BALRs! USING TEST,R12 Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Charles Mills Sent: Saturday, April 2, 2022 9:25 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Eliminating Base Registers (was: Inlining routines) A couple of things. One, yes, my assertion that it is easy was based on my own experience primarily with modest-sized programs that I had written myself -- in some cases years earlier. If you are talking about 10,000 lines of spaghetti enhanced over the years by lots of folks, with embedded local macros and various cleverness, then it could be a large and fraught project. Two, I am not advocating for "baseless" programming -- eliminating base registers like they were forbidden GOTOs in some COBOL program. a. Relative jumps are goodness in any event. They are thought to be generally faster than based branches. So even if you did nothing else, replacing 90% of your branches with jumps could be a good thing. b. I think all of my programs use a code base register. One code base register. One. I am advocating for (i) getting rid of "4K anxiety" and (ii) freeing up a register or two in those old programs with two or three code base registers. Here's the structure (and apologies for starting from @Peter's example) -- untested, of course TEST CSECT MAIN1LOCTR M1 DC'Eyecatcher at front of CSECT' MAIN2LOCTR DSHalignment MYENTRY EQU * ENTRY MYENTRY SAVE ... LARL R12,MAIN1 no more BALRs! USING MAIN1,R12 code ... MAIN1LOCTR * put any macros that need a base in little subroutines here LTORG Small constants and, if CSECT not relocatable, work areas MAIN2LOCTR Any large buffers or tables END So long as MAIN1 is less than 4K the whole thing will work with just the one code base register, no matter how long MAIN2 is. The organization in storage is R12 points here --> MAIN1 Eyecatcher LTORG Macro subroutines Small constants MAIN2 Main code 4K addressability ends somewhere above or below here Large buffers and tables Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Bernd Oppolzer Sent: Friday, April 1, 2022 2:51 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Eliminating Base Registers (was: Inlining routines) See some answers below. In general the elimination of base registers for the code section with existing large programs is a major task and needs careful testing. I did this sometimes, and I had many issues and headaches, until the programs worked (again). More hints below ... Kind regards Bernd Am 01.04.2022 um 20:41 schrieb Dave Clark: > "IBM Mainframe Assembler List" wrote on > 04/01/2022 02:14:38 PM: >> Where I disagree is on the base register issue. Base registers and >> code addressability issues should have gone away. It is pretty >> trivial to replace old branches with their newer relative >> counterparts. Should be faster code, too, FWIW. > > OK, I'll bite. This discussion has probably been done before but > I wasn't around for that. Forgive my newbie questions -- even though I > have been programming in assembler on and off since 1978. That said... > > I understand relative branching on a basic level. But I haven't > really looked into them and haven't used them at all to this point. So... > > 1. Is it as simple as just using a different mnemonic for the branch? In general, yes, but, see above, there are different problems, with IBM or site-specific macros which generate inline definitions etc. and literals etc. ... and which assume that there is a base register which covers the code section. You can change them, or you can establish a temporary base (maybe register 1,14, 15) around the macro call. > 2. Does the target label still have to be within 4K for the relative > branch? No, even the simple relative branches can reach 64 k in both directions from the current PSW > 3. ...or is there an extended relative branch that uses the extended > displacement feature? there are extended branches, but when converting existing programs, you normally don't need them > 4. What about the target for the EXecute instruction? Is there a relative > version of this? no need for this during normal conversion, because you need a base register for the data part, anyway, and the target of the EX is in the data part > 5. Even if code base register(s) is(are) eliminated, you still need a data > base register -- yes? yes, sure. If you read my
Re: Eliminating Base Registers (was: Inlining routines)
A couple of things. One, yes, my assertion that it is easy was based on my own experience primarily with modest-sized programs that I had written myself -- in some cases years earlier. If you are talking about 10,000 lines of spaghetti enhanced over the years by lots of folks, with embedded local macros and various cleverness, then it could be a large and fraught project. Two, I am not advocating for "baseless" programming -- eliminating base registers like they were forbidden GOTOs in some COBOL program. a. Relative jumps are goodness in any event. They are thought to be generally faster than based branches. So even if you did nothing else, replacing 90% of your branches with jumps could be a good thing. b. I think all of my programs use a code base register. One code base register. One. I am advocating for (i) getting rid of "4K anxiety" and (ii) freeing up a register or two in those old programs with two or three code base registers. Here's the structure (and apologies for starting from @Peter's example) -- untested, of course TEST CSECT MAIN1LOCTR M1 DC'Eyecatcher at front of CSECT' MAIN2LOCTR DSHalignment MYENTRY EQU * ENTRY MYENTRY SAVE ... LARL R12,MAIN1 no more BALRs! USING MAIN1,R12 code ... MAIN1LOCTR * put any macros that need a base in little subroutines here LTORG Small constants and, if CSECT not relocatable, work areas MAIN2LOCTR Any large buffers or tables END So long as MAIN1 is less than 4K the whole thing will work with just the one code base register, no matter how long MAIN2 is. The organization in storage is R12 points here --> MAIN1 Eyecatcher LTORG Macro subroutines Small constants MAIN2 Main code 4K addressability ends somewhere above or below here Large buffers and tables Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Bernd Oppolzer Sent: Friday, April 1, 2022 2:51 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Eliminating Base Registers (was: Inlining routines) See some answers below. In general the elimination of base registers for the code section with existing large programs is a major task and needs careful testing. I did this sometimes, and I had many issues and headaches, until the programs worked (again). More hints below ... Kind regards Bernd Am 01.04.2022 um 20:41 schrieb Dave Clark: > "IBM Mainframe Assembler List" wrote on > 04/01/2022 02:14:38 PM: >> Where I disagree is on the base register issue. Base registers and >> code addressability issues should have gone away. It is pretty >> trivial to replace old branches with their newer relative >> counterparts. Should be faster code, too, FWIW. > > OK, I'll bite. This discussion has probably been done before but > I wasn't around for that. Forgive my newbie questions -- even though I > have been programming in assembler on and off since 1978. That said... > > I understand relative branching on a basic level. But I haven't > really looked into them and haven't used them at all to this point. So... > > 1. Is it as simple as just using a different mnemonic for the branch? In general, yes, but, see above, there are different problems, with IBM or site-specific macros which generate inline definitions etc. and literals etc. ... and which assume that there is a base register which covers the code section. You can change them, or you can establish a temporary base (maybe register 1,14, 15) around the macro call. > 2. Does the target label still have to be within 4K for the relative > branch? No, even the simple relative branches can reach 64 k in both directions from the current PSW > 3. ...or is there an extended relative branch that uses the extended > displacement feature? there are extended branches, but when converting existing programs, you normally don't need them > 4. What about the target for the EXecute instruction? Is there a relative > version of this? no need for this during normal conversion, because you need a base register for the data part, anyway, and the target of the EX is in the data part > 5. Even if code base register(s) is(are) eliminated, you still need a data > base register -- yes? yes, sure. If you read my former post about local procedures, which had for example two base registers in the past, you may now reduce the two base registers to one, and the one covers the "local" data area of the local procedure, which is the data area which lies behind the code section of the local procedure. The code section doesn't need a base register any mor
Re: Eliminating Base Registers (was: Inlining routines)
I would like to add: I saw old large programs with mixed code and data areas where some people without much knowlegde simply used 3, 4 or 5 base registers to covers the whole program, no matter if it consisted of code sections, data areas or subroutines. Of course, they ran out of registers. When I had to do maintenance on them, I simply inserted some of my procedure macros to make the "subroutines" to units which have individual base registers (all the same), this way reducing the number of overall base registers from 5 to 2. This was done WITHOUT converting the program to baseless. The change was a pure technical change, and turned the programs immediately in a maintainable state. This was on VSE, BTW. Kind regards Bernd Am 01.04.2022 um 23:50 schrieb Bernd Oppolzer: See some answers below. In general the elimination of base registers for the code section with existing large programs is a major task and needs careful testing. I did this sometimes, and I had many issues and headaches, until the programs worked (again). More hints below ... Kind regards Bernd Am 01.04.2022 um 20:41 schrieb Dave Clark: "IBM Mainframe Assembler List" wrote on 04/01/2022 02:14:38 PM: Where I disagree is on the base register issue. Base registers and code addressability issues should have gone away. It is pretty trivial to replace old branches with their newer relative counterparts. Should be faster code, too, FWIW. OK, I'll bite. This discussion has probably been done before but I wasn't around for that. Forgive my newbie questions -- even though I have been programming in assembler on and off since 1978. That said... I understand relative branching on a basic level. But I haven't really looked into them and haven't used them at all to this point. So... 1. Is it as simple as just using a different mnemonic for the branch? In general, yes, but, see above, there are different problems, with IBM or site-specific macros which generate inline definitions etc. and literals etc. ... and which assume that there is a base register which covers the code section. You can change them, or you can establish a temporary base (maybe register 1,14, 15) around the macro call. 2. Does the target label still have to be within 4K for the relative branch? No, even the simple relative branches can reach 64 k in both directions from the current PSW 3. ...or is there an extended relative branch that uses the extended displacement feature? there are extended branches, but when converting existing programs, you normally don't need them 4. What about the target for the EXecute instruction? Is there a relative version of this? no need for this during normal conversion, because you need a base register for the data part, anyway, and the target of the EX is in the data part 5. Even if code base register(s) is(are) eliminated, you still need a data base register -- yes? yes, sure. If you read my former post about local procedures, which had for example two base registers in the past, you may now reduce the two base registers to one, and the one covers the "local" data area of the local procedure, which is the data area which lies behind the code section of the local procedure. The code section doesn't need a base register any more. With the older technique, both code and data area were limited to 8 k; now the data area is limited to 4k, but the code area is unlimited (if you manage to get is baseless). 6. If you have a large program with constant data at the end of the program, how do you establish the base register needed for that data area? you should IMO move the "global" data after the code section for the mainline, and then establish a base register from the mainline, which makes this global data section available for all "local subroutines". This way, you can access all data with only two base registers, say 10 and 11: 10 for the global data area, and 11 for all the local data areas; every local procedures assigns reg 11 to the base address of its local ares on entry. The addressing of these areas is always established using address constants. 7. Lastly, if the code base register has been eliminated, does this mean you should no longer have things like LTORG at the end of each subroutine to force data to be stored near the subroutine that uses it (where previously the code base register for the subroutine would have served double-duty as the data base register)? you need LTORG as before; see above ... you still have a base register which points at the data area for every subroutine. The difference to the older solution is that the base address now is not the beginning of the subroutine but instead somewhere near the end and that the base register does not cover the code section (and the data section) but only the data section, which lies behind the code section. The LTORG
Re: Eliminating Base Registers (was: Inlining routines)
See some answers below. In general the elimination of base registers for the code section with existing large programs is a major task and needs careful testing. I did this sometimes, and I had many issues and headaches, until the programs worked (again). More hints below ... Kind regards Bernd Am 01.04.2022 um 20:41 schrieb Dave Clark: "IBM Mainframe Assembler List" wrote on 04/01/2022 02:14:38 PM: Where I disagree is on the base register issue. Base registers and code addressability issues should have gone away. It is pretty trivial to replace old branches with their newer relative counterparts. Should be faster code, too, FWIW. OK, I'll bite. This discussion has probably been done before but I wasn't around for that. Forgive my newbie questions -- even though I have been programming in assembler on and off since 1978. That said... I understand relative branching on a basic level. But I haven't really looked into them and haven't used them at all to this point. So... 1. Is it as simple as just using a different mnemonic for the branch? In general, yes, but, see above, there are different problems, with IBM or site-specific macros which generate inline definitions etc. and literals etc. ... and which assume that there is a base register which covers the code section. You can change them, or you can establish a temporary base (maybe register 1,14, 15) around the macro call. 2. Does the target label still have to be within 4K for the relative branch? No, even the simple relative branches can reach 64 k in both directions from the current PSW 3. ...or is there an extended relative branch that uses the extended displacement feature? there are extended branches, but when converting existing programs, you normally don't need them 4. What about the target for the EXecute instruction? Is there a relative version of this? no need for this during normal conversion, because you need a base register for the data part, anyway, and the target of the EX is in the data part 5. Even if code base register(s) is(are) eliminated, you still need a data base register -- yes? yes, sure. If you read my former post about local procedures, which had for example two base registers in the past, you may now reduce the two base registers to one, and the one covers the "local" data area of the local procedure, which is the data area which lies behind the code section of the local procedure. The code section doesn't need a base register any more. With the older technique, both code and data area were limited to 8 k; now the data area is limited to 4k, but the code area is unlimited (if you manage to get is baseless). 6. If you have a large program with constant data at the end of the program, how do you establish the base register needed for that data area? you should IMO move the "global" data after the code section for the mainline, and then establish a base register from the mainline, which makes this global data section available for all "local subroutines". This way, you can access all data with only two base registers, say 10 and 11: 10 for the global data area, and 11 for all the local data areas; every local procedures assigns reg 11 to the base address of its local ares on entry. The addressing of these areas is always established using address constants. 7. Lastly, if the code base register has been eliminated, does this mean you should no longer have things like LTORG at the end of each subroutine to force data to be stored near the subroutine that uses it (where previously the code base register for the subroutine would have served double-duty as the data base register)? you need LTORG as before; see above ... you still have a base register which points at the data area for every subroutine. The difference to the older solution is that the base address now is not the beginning of the subroutine but instead somewhere near the end and that the base register does not cover the code section (and the data section) but only the data section, which lies behind the code section. The LTORG should be located directly following the return instructions, at the end of the code section of the subroutine. Sincerely, Dave Clark
RES: Eliminating Base Registers (was: Inlining routines)
You may use OPSYN to replace instructions to use 20 bits displacement instead of 12, and change B to J, for example: L OPSYN LY LA OPSYN LAY B OPSYN J BL OPSYN JL BE OPSYN JE And so on ... João -Mensagem original- De: IBM Mainframe Assembler List Em nome de Martin Trübner Enviada em: sexta-feira, 1 de abril de 2022 16:54 Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU Assunto: Re: Eliminating Base Registers (was: Inlining routines) VSE does not have IEABRX(X) but it has MAKEREL you can find it on the vmworkshop page http://workshop.velocitysoftware.com/martin/index.shtml Martin
Re: Eliminating Base Registers (was: Inlining routines)
VSE does not have IEABRX(X) but it has MAKEREL you can find it on the vmworkshop page http://workshop.velocitysoftware.com/martin/index.shtml Martin
Re: Eliminating Base Registers (was: Inlining routines)
I recommend using change in an editor anyway, so you keep control of the process. YMMV If you run into IBM or other macro problems, cross that bridge when you come to it. IEABRCX can be "turned on" and "turned off" at various points in the source code if necessary. No idea if it is available for VSE, but there is nothing inherently "z/OS" about it -- pure hardware assembler, I believe. Or you could roll your own. Is there anything like the SYSSTATE ARCHLVL= macro in VSE? *Some* IBM macros are responsive to it and will generate relative branches "natively" if you are at a sufficient level. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dave Clark Sent: Friday, April 1, 2022 12:32 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Eliminating Base Registers (was: Inlining routines) "IBM Mainframe Assembler List" wrote on 04/01/2022 02:51:13 PM: > some brief comments: > plus IBM macros have to be converted, there should be a macro to do that Thanks. I did some reading at the link subsequently sent to this and I checked my system. Apparently that macro (IEABRCX) was not made available to the z/VSE mainframe environment -- at least, not at my level. We are 10 or 12 years behind on upgrades. ;-)We will be upgrading to the latest level in the next two months, though, and I can check again. Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378 home: (937) 751-3300 Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
Re: Eliminating Base Registers (was: Inlining routines)
"IBM Mainframe Assembler List" wrote on 04/01/2022 03:32:42 PM: > Just go for it! Relative branches are 100% goodness, the best thing in > assembler since ICM. Easy as pi. > > Find a B opcode and replace it with a J. Find a BE opcode and replace it > with a JE. Convince yourself of how easy this is going to be, and then just > do it. > > Only classic B SOMELABEL branches. J does not replace branch table branches > like B 4(R1,R15) or B FOOBAR(R2). I generally don't use the last two forms of branching so I am good from that standpoint. My recent project (external assembler REXX function for VSAM I/O) is what got me thinking more seriously about eliminating the need for code base registers. The main routine links three base registers to cover the code and trailing constants -- in spite of splitting out to four other external subroutines to get everything done. Losing the more general use of three registers really hurt. ;-) Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378 home: (937) 751-3300 Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
Re: Eliminating Base Registers (was: Inlining routines)
Just go for it! Relative branches are 100% goodness, the best thing in assembler since ICM. Easy as pi. Find a B opcode and replace it with a J. Find a BE opcode and replace it with a JE. Convince yourself of how easy this is going to be, and then just do it. Only classic B SOMELABEL branches. J does not replace branch table branches like B 4(R1,R15) or B FOOBAR(R2). Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dave Clark Sent: Friday, April 1, 2022 11:42 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Eliminating Base Registers (was: Inlining routines) "IBM Mainframe Assembler List" wrote on 04/01/2022 02:14:38 PM: > Where I disagree is on the base register issue. Base registers and > code addressability issues should have gone away. It is pretty > trivial to replace old branches with their newer relative > counterparts. Should be faster code, too, FWIW. OK, I'll bite. This discussion has probably been done before but I wasn't around for that. Forgive my newbie questions -- even though I have been programming in assembler on and off since 1978. That said... I understand relative branching on a basic level. But I haven't really looked into them and haven't used them at all to this point. So... 1. Is it as simple as just using a different mnemonic for the branch? 2. Does the target label still have to be within 4K for the relative branch? 3. ...or is there an extended relative branch that uses the extended displacement feature? 4. What about the target for the EXecute instruction? Is there a relative version of this? 5. Even if code base register(s) is(are) eliminated, you still need a data base register -- yes? 6. If you have a large program with constant data at the end of the program, how do you establish the base register needed for that data area? 7. Lastly, if the code base register has been eliminated, does this mean you should no longer have things like LTORG at the end of each subroutine to force data to be stored near the subroutine that uses it (where previously the code base register for the subroutine would have served double-duty as the data base register)? Sincerely, Dave Clark -- Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
Re: Eliminating Base Registers (was: Inlining routines)
"IBM Mainframe Assembler List" wrote on 04/01/2022 02:51:13 PM: > some brief comments: > plus IBM macros have to be converted, there should be a macro to do that Thanks. I did some reading at the link subsequently sent to this and I checked my system. Apparently that macro (IEABRCX) was not made available to the z/VSE mainframe environment -- at least, not at my level. We are 10 or 12 years behind on upgrades. ;-)We will be upgrading to the latest level in the next two months, though, and I can check again. Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378 home: (937) 751-3300 Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
Re: Eliminating Base Registers (was: Inlining routines)
Don't use IEABRCX with LE-enabled assembler! There is (or was -- perhaps they fixed it) a dependency on opcode 47 in EDCPRLG. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, April 1, 2022 11:59 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Eliminating Base Registers (was: Inlining routines) On Apr 1, 2022, at 12:51:13, Gary Weinhold wrote: > > some brief comments: > plus IBM macros have to be converted, there should be a macro to do that > <https://www.ibm.com/docs/en/zos/2.5.0?topic=xct-ieabrcx-relative-branch-mac ro-extension> > On 2022-04-01 2:41 p.m., Dave Clark wrote: >> "IBM Mainframe Assembler List" wrote on >> 04/01/2022 02:14:38 PM: >>> Where I disagree is on the base register issue. Base registers and >>> code addressability issues should have gone away. It is pretty >>> trivial to replace old branches with their newer relative >>> counterparts. Should be faster code, too, FWIW. >> >>OK, I'll bite. This discussion has probably been done before but >> I wasn't around for that. Forgive my newbie questions -- even though I >> have been programming in assembler on and off since 1978. That said... -- gil
Re: Eliminating Base Registers (was: Inlining routines)
On Apr 1, 2022, at 12:51:13, Gary Weinhold wrote: > > some brief comments: > plus IBM macros have to be converted, there should be a macro to do that > <https://www.ibm.com/docs/en/zos/2.5.0?topic=xct-ieabrcx-relative-branch-macro-extension> > On 2022-04-01 2:41 p.m., Dave Clark wrote: >> "IBM Mainframe Assembler List" wrote on >> 04/01/2022 02:14:38 PM: >>> Where I disagree is on the base register issue. Base registers and >>> code addressability issues should have gone away. It is pretty >>> trivial to replace old branches with their newer relative >>> counterparts. Should be faster code, too, FWIW. >> >>OK, I'll bite. This discussion has probably been done before but >> I wasn't around for that. Forgive my newbie questions -- even though I >> have been programming in assembler on and off since 1978. That said... -- gil
Re: Eliminating Base Registers (was: Inlining routines)
1. Pretty much. So much so that there is an IBM supplied macro that will just do a 1 for 1 mindless replacement. I recommend using change in a text editor instead but YMMV. 2. No. I have forgotten the range because it has never bitten me. +/-65K? Someone will correct me. 3. I believe so. Never used it. The link editor is smart enough that you can jump from one module to another, believe it or not. 4. Yes, but newer than the relative branches. Check the ARCH level to be sure you have it. 5. Yes, but IMHO likely to be less of a problem. 6. I use LOCTR to take things that I define late in the source code and put them at the front of the object code. Pretty simple. 7. Best for performance to move data more than 256 bytes away from code, and to keep code as compact as possible. In other words, data with data, instructions with instructions. Read-only data with read-only data, read-write data with read-write data. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dave Clark Sent: Friday, April 1, 2022 11:42 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Eliminating Base Registers (was: Inlining routines) "IBM Mainframe Assembler List" wrote on 04/01/2022 02:14:38 PM: > Where I disagree is on the base register issue. Base registers and > code addressability issues should have gone away. It is pretty > trivial to replace old branches with their newer relative > counterparts. Should be faster code, too, FWIW. OK, I'll bite. This discussion has probably been done before but I wasn't around for that. Forgive my newbie questions -- even though I have been programming in assembler on and off since 1978. That said... I understand relative branching on a basic level. But I haven't really looked into them and haven't used them at all to this point. So... 1. Is it as simple as just using a different mnemonic for the branch? 2. Does the target label still have to be within 4K for the relative branch? 3. ...or is there an extended relative branch that uses the extended displacement feature? 4. What about the target for the EXecute instruction? Is there a relative version of this? 5. Even if code base register(s) is(are) eliminated, you still need a data base register -- yes? 6. If you have a large program with constant data at the end of the program, how do you establish the base register needed for that data area? 7. Lastly, if the code base register has been eliminated, does this mean you should no longer have things like LTORG at the end of each subroutine to force data to be stored near the subroutine that uses it (where previously the code base register for the subroutine would have served double-duty as the data base register)? Sincerely, Dave Clark -- Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
Re: Eliminating Base Registers (was: Inlining routines)
some brief comments: plus IBM macros have to be converted, there should be a macro to do that On 2022-04-01 2:41 p.m., Dave Clark wrote: "IBM Mainframe Assembler List" wrote on 04/01/2022 02:14:38 PM: Where I disagree is on the base register issue. Base registers and code addressability issues should have gone away. It is pretty trivial to replace old branches with their newer relative counterparts. Should be faster code, too, FWIW. OK, I'll bite. This discussion has probably been done before but I wasn't around for that. Forgive my newbie questions -- even though I have been programming in assembler on and off since 1978. That said... I understand relative branching on a basic level. But I haven't really looked into them and haven't used them at all to this point. So... 1. Is it as simple as just using a different mnemonic for the branch? Yes 2. Does the target label still have to be within 4K for the relative branch? No 3. ...or is there an extended relative branch that uses the extended displacement feature? The default is extended 4. What about the target for the EXecute instruction? Is there a relative version of this? EXRL 5. Even if code base register(s) is(are) eliminated, you still need a data base register -- yes? Reentrant, of course; there are some relative data reference commands 6. If you have a large program with constant data at the end of the program, how do you establish the base register needed for that data area? LARL will get the address 7. Lastly, if the code base register has been eliminated, does this mean you should no longer have things like LTORG at the end of each subroutine to force data to be stored near the subroutine that uses it (where previously the code base register for the subroutine would have served double-duty as the data base register)? Yes but more immediate instructions may mean less need for literals Sincerely, Dave Clark Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com 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.
Eliminating Base Registers (was: Inlining routines)
"IBM Mainframe Assembler List" wrote on 04/01/2022 02:14:38 PM: > Where I disagree is on the base register issue. Base registers and > code addressability issues should have gone away. It is pretty > trivial to replace old branches with their newer relative > counterparts. Should be faster code, too, FWIW. OK, I'll bite. This discussion has probably been done before but I wasn't around for that. Forgive my newbie questions -- even though I have been programming in assembler on and off since 1978. That said... I understand relative branching on a basic level. But I haven't really looked into them and haven't used them at all to this point. So... 1. Is it as simple as just using a different mnemonic for the branch? 2. Does the target label still have to be within 4K for the relative branch? 3. ...or is there an extended relative branch that uses the extended displacement feature? 4. What about the target for the EXecute instruction? Is there a relative version of this? 5. Even if code base register(s) is(are) eliminated, you still need a data base register -- yes? 6. If you have a large program with constant data at the end of the program, how do you establish the base register needed for that data area? 7. Lastly, if the code base register has been eliminated, does this mean you should no longer have things like LTORG at the end of each subroutine to force data to be stored near the subroutine that uses it (where previously the code base register for the subroutine would have served double-duty as the data base register)? Sincerely, Dave Clark -- Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
Re: Base registers
John, >> I think VSE doesn't support GOFF. That is true- the requirement has been raised long ago- but it is still open. >> ... whether it has added support for relative-immediate external references, but it should be easy to test. I did. Here is what I get (in line with above): ** ASMA215W Relative Immediate external relocation in NOGOFF object text To be honest: this support would be a nice there (not even "to have") item. What is required is (with GOFF support) long names. What is even more required is a working ADEXIT (!). -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: Base registers
Martin Truebner asked >> ...both old OBJ...object formats since 2004. >Would that include z/VSE (any) I think VSE doesn't support GOFF. I don't whether it has added support for relative-immediate external references, but it should be easy to test. John Ehrman
Re: Base registers
John, >> ...both old OBJ...object formats since 2004. Would that include z/VSE (any) -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: Base registers
> -Original Message- > From: IBM Mainframe Assembler List > [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John Ehrman > Sent: Tuesday, June 19, 2012 11:55 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base registers > > >> ... I prefer using Branch Relative, Relative (such as LARL > vice LAY), > and Immediate (such as LHI vice LH) instructions. And I do > recognize that > it is not always >possible, such as accessing locations outside of the > enclosing CSECT. > >> > >That would require an enhancement to Binder. But that's not > >unthinkable. But it would introduce a class of addressability > >errors that could be detected only at link time, not at assembly. > >Probably not justified by ROI. > > Relative-immediate references to external symbols has been > available for > both old OBJ and new GOFF object formats since 2004. > > John Ehrman I'm not up on the enhancements which can be exploited when GOFF is used. I've only started using GOFF since I've learned how to write LE DLLs in HLASM. And I'm just weird enough to have actually done and so that I could use the DLL in a z/UNIX command, written in LE enabled HLASM. All of which I could gladly abandon if I could get a C license. Ain't gonna happen no time soon 'round heayr. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Re: Base registers
>> ... I prefer using Branch Relative, Relative (such as LARL vice LAY), and Immediate (such as LHI vice LH) instructions. And I do recognize that it is not always >possible, such as accessing locations outside of the enclosing CSECT. >> >That would require an enhancement to Binder. But that's not >unthinkable. But it would introduce a class of addressability >errors that could be detected only at link time, not at assembly. >Probably not justified by ROI. Relative-immediate references to external symbols has been available for both old OBJ and new GOFF object formats since 2004. John Ehrman
Re: Base registers
You can refer to entry points outside of the current CSECT if you specify the GOFF assembler option. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2012-06-19 10:04, Paul Gilmartin wrote: On Jun 19, 2012, at 07:51, McKown, John wrote: ... I prefer using Branch Relative, Relative (such as LARL vice LAY), and Immediate (such as LHI vice LH) instructions. And I do recognize that it is not always possible, such as accessing locations outside of the enclosing CSECT. That would require an enhancement to Binder. But that's not unthinkable. But it would introduce a class of addressability errors that could be detected only at link time, not at assembly. Probably not justified by ROI. -- gil
Re: Base registers
On Tue, 19 Jun 2012 08:04:35 -0600, Paul Gilmartin wrote: >On Jun 19, 2012, at 07:51, McKown, John wrote: >> >> ... I prefer using Branch Relative, Relative (such as >>LARL vice LAY), and Immediate (such as LHI vice LH) >>instructions. And I do recognize that it is not always >>possible, such as accessing locations outside of the >>enclosing CSECT. >> >That would require an enhancement to Binder. Binder and HLASM. I've not used it yet, but it is there. -- Tom Marchant
Re: Base registers
JRI is nice and short. Again, almost anything simple is acceptable to me. I originally used "baseless" because that was what I saw in many messages. I'm now bowing out of the discussion and awaiting for a concensus to occur. I will just reiterate that, to the extent possible, I prefer using Branch Relative, Relative (such as LARL vice LAY), and Immediate (such as LHI vice LH) instructions. And I do recognize that it is not always possible, such as accessing locations outside of the enclosing CSECT. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -Original Message- > From: IBM Mainframe Assembler List > [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John Gilmore > Sent: Tuesday, June 19, 2012 8:45 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base registers > > "Jumpify" is acceptable as a nonce word, in, say, EJ's title. > > It is nevertheless barbarous English and should not be adopted for > routine use. > > "JRI"? > > --jg > > On 6/19/12, McKown, John wrote: > > OK, I can live with "jumpify". I would just like something that is > > "generally acceptable" to the community. Only minus is that > it doesn't say > > anything about the use of Relative and Immediate > instructions. Of which I am > > also a big fan. > > > > -- > > John McKown > > Systems Engineer IV > > IT > > > > Administrative Services Group > > > > HealthMarkets(r) > > > > 9151 Boulevard 26 * N. Richland Hills * TX 76010 > > (817) 255-3225 phone * > > john.mck...@healthmarkets.com * www.HealthMarkets.com > > > > Confidentiality Notice: This e-mail message may contain > confidential or > > proprietary information. If you are not the intended > recipient, please > > contact the sender by reply e-mail and destroy all copies > of the original > > message. HealthMarkets(r) is the brand name for products > underwritten and > > issued by the insurance subsidiaries of HealthMarkets, Inc. > -The Chesapeake > > Life Insurance Company(r), Mid-West National Life Insurance > Company of > > TennesseeSM and The MEGA Life and Health Insurance Company.SM > > > >
Re: Base registers
On Jun 19, 2012, at 07:51, McKown, John wrote: > > ... I prefer using Branch Relative, Relative (such as LARL vice LAY), and > Immediate (such as LHI vice LH) instructions. And I do recognize that it is > not always possible, such as accessing locations outside of the enclosing > CSECT. > That would require an enhancement to Binder. But that's not unthinkable. But it would introduce a class of addressability errors that could be detected only at link time, not at assembly. Probably not justified by ROI. -- gil
Re: Base registers
"Jumpify" is acceptable as a nonce word, in, say, EJ's title. It is nevertheless barbarous English and should not be adopted for routine use. "JRI"? --jg On 6/19/12, McKown, John wrote: > OK, I can live with "jumpify". I would just like something that is > "generally acceptable" to the community. Only minus is that it doesn't say > anything about the use of Relative and Immediate instructions. Of which I am > also a big fan. > > -- > John McKown > Systems Engineer IV > IT > > Administrative Services Group > > HealthMarkets(r) > > 9151 Boulevard 26 * N. Richland Hills * TX 76010 > (817) 255-3225 phone * > john.mck...@healthmarkets.com * www.HealthMarkets.com > > Confidentiality Notice: This e-mail message may contain confidential or > proprietary information. If you are not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the original > message. HealthMarkets(r) is the brand name for products underwritten and > issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake > Life Insurance Company(r), Mid-West National Life Insurance Company of > TennesseeSM and The MEGA Life and Health Insurance Company.SM >
Re: Base registers
To make it IBM-like, you'd have to call it the "Jumpify Facility". :-) -- From: "Peter Relson" Sent: Tuesday, June 19, 2012 9:21 AM To: Subject: Re: Base registers My quibble with the terms being bandied about is that neither "unbased" nor "baseless" is factually correct for a large percentage of modules that use relative branches. They have a "base" to their static data (and, yes, sometimes that "base" is not persistent and is created only when needed). They just do not tend to need a base for their code (aside from when they use macros that have not been "jumpified"). If you think of the addressablity to code as being via "codereg" they have been de-codereg'd (not a pleasing term, of course). I think everyone these days understands what someone means when they use the non-word "jumpify". Is more than that needed? Creating more terminology just for the sake of doing so seems unwieldy (and perhaps it could be said "IBM-like"). Peter Relson z/OS Core Technology Design
Re: Base registers
OK, I can live with "jumpify". I would just like something that is "generally acceptable" to the community. Only minus is that it doesn't say anything about the use of Relative and Immediate instructions. Of which I am also a big fan. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Re: Base registers
My quibble with the terms being bandied about is that neither "unbased" nor "baseless" is factually correct for a large percentage of modules that use relative branches. They have a "base" to their static data (and, yes, sometimes that "base" is not persistent and is created only when needed). They just do not tend to need a base for their code (aside from when they use macros that have not been "jumpified"). If you think of the addressablity to code as being via "codereg" they have been de-codereg'd (not a pleasing term, of course). I think everyone these days understands what someone means when they use the non-word "jumpify". Is more than that needed? Creating more terminology just for the sake of doing so seems unwieldy (and perhaps it could be said "IBM-like"). Peter Relson z/OS Core Technology Design
Re: Base registers
On Sun, 17 Jun 2012 17:01:05 -0400, John Gilmore wrote: >Unbased is better by a wide margin than baseless. > >I should still, however, prefer a non-negative form. I don't have an entirely satisfactory suggestion, but I sometimes refer to it as "Relative code". IMO, Unbased suffers from the same problem as Baseless, that it is inaccurate. Base registers are still needed for data. Relative addressing removes the requirement for most code. -- Tom Marchant
Re: Base registers
> -Original Message- > From: IBM Mainframe Assembler List > [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Rob van der Heij > Sent: Monday, June 18, 2012 6:23 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base registers > > On Mon, Jun 18, 2012 at 10:36 AM, Thomas Berg > wrote: > > > All your bases are belong to us ? > > LOL. Just when I was convinced we had cross-talk with the > IBM-MAIN list ;-) > > May the source be with you... Which is guaranteed if you use only GPL'd software! "Just say NO to OCO!" still lives. Confirmed Penguinista, John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Re: Base registers
Steve Comstock wrote: >I was going to suggest 'free base' as a 'positive' way >of saying one is relatively free from using base registers, >but that term also has unfortunate conotations. Indeed..."debased" would be my choice! :-) ...phsiii
Re: Base registers
On 6/18/2012 4:05 AM, Fred van der Windt wrote: All your bases are belong to us ? For great justice. Fred! Says the Dutchman replying to the Swede! I love this list! -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html
Re: Base registers
On Mon, Jun 18, 2012 at 10:36 AM, Thomas Berg wrote: > All your bases are belong to us ? LOL. Just when I was convinced we had cross-talk with the IBM-MAIN list ;-) May the source be with you...
Re: Base registers
> All your bases are belong to us ? For great justice. 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. -
SV: Base registers
All your bases are belong to us ? Regards, Thomas Berg ___ Thomas Berg Specialist AM/SM&S SWEDBANK AB (publ) > -Ursprungligt meddelande- > Från: IBM Mainframe Assembler List [mailto:ASSEMBLER- > l...@listserv.uga.edu] För John Gilmore > Skickat: den 17 juni 2012 23:01 > Till: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Ämne: Re: Base registers > > Unbased is better by a wide margin than baseless. > > I should still, however, prefer a non-negative form. > > John Gilmore, Ashland, MA 01721 - USA > > On 6/17/12, Gerhard Postpischil wrote: > > On 6/17/2012 9:05 AM, John Gilmore wrote: > >> Words can of course have different specialized meanings in different > >> contexts, but there is ordinarily an evolutionary path between these > >> meanings. > > > > My favorite along these lines is "stench", that did not always > > mean unpleasant. I vividly remember a streetcar ride where > > almost every passenger carried freshly cut lilacs, to the point > > where the smell was overpowering, though not unpleasant. > > > >> Alternative suggestions? > > > > I used "unbased". > > > > Gerhard Postpischil > > Bradford, VT > >
Re: Base registers
On Mon, 18 Jun 2012 11:24:14 +1000 Robin Vowels wrote: :>From: "Watkins, Douglas" :>Sent: Wednesday, 6 June 2012 11:28 PM :>> Here's one way to do standard EXecute without a base register: > :>> AHI R2,-1 Minus 1 for EX :>BTW, :>BCTR 2,0 will do a better job. Unless you place a JM after the AHI -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies.
Re: Base registers
On Mon, Jun 18, 2012 at 6:52 AM, Gerhard Postpischil wrote: > Not sure what's confusing about it; I've had an INC for ages (no > DEC, instead put INC=-1 on INC - that may be confusing?). It > changes either a register or storage, and had a version for > halfwords named INCH Yep! It's a ver useful way to abstract from the actual implementation. It helps distinguish the BCTR x,0 from the ones that implement a loop. Since I have *no* branch instructions or labels in my new code other than generated by structured programming macros, going to basefree code will only take changes to the macros. A BCTR would stand out more than I want. Rob
Re: Base registers
On 6/17/2012 10:44 PM, John McKown wrote: As an aside, I was actually (foolishly) considering making macros called DEC (as in DEC Reg,Value => AHI Reg,0-&Value with default of 1), INC (INC Reg,Value => AHI Reg,Value, default of 1), PRED Reg (DEC Reg,1), SUCC Reg (INC Reg). Then realized it would likely be more confusing than helpful. Not sure what's confusing about it; I've had an INC for ages (no DEC, instead put INC=-1 on INC - that may be confusing?). It changes either a register or storage, and had a version for halfwords named INCH Gerhard Postpischil Bradford, VT
Re: Base registers
On Mon, 2012-06-18 at 11:24 +1000, Robin Vowels wrote: > From: "Watkins, Douglas" > Sent: Wednesday, 6 June 2012 11:28 PM > > > > Here's one way to do standard EXecute without a base register: > > > > AHI R2,-1 Minus 1 for EX > > BTW, > BCTR 2,0 will do a better job. I agree. It is two bytes shorter. Possibly faster. Does not disturb the condition code. And is a generally understood standard notation. Might even be considered like the DECrement instruction in other assemblers. As an aside, I was actually (foolishly) considering making macros called DEC (as in DEC Reg,Value => AHI Reg,0-&Value with default of 1), INC (INC Reg,Value => AHI Reg,Value, default of 1), PRED Reg (DEC Reg,1), SUCC Reg (INC Reg). Then realized it would likely be more confusing than helpful. -- John McKown Maranatha! <><
Re: Base registers
From: "Watkins, Douglas" Sent: Wednesday, 6 June 2012 11:28 PM Here's one way to do standard EXecute without a base register: AHI R2,-1 Minus 1 for EX BTW, BCTR 2,0 will do a better job.
Re: Base registers
Just my two cents: 1. There are architectures which have always had relative addressing, and use that term. 2. Some day, relative braches will be the norm and not the exception. As time goes on, any term with "base" as the root (e.g. unbased, baseless, etc.) is likely to need increasingly superfluous explanations to novices. Thus, I suggest "relative branch" and/or "jump" should suffice. For the exclusive case (non-base register branching) perhaps "relative-only branching" and/or "jump-only" program[ming]. On Sun, Jun 17, 2012 at 5:38 PM, J R wrote: > Sorry Steve. I didn't see your post until after I posted mine. > > === > > > Date: Sun, 17 Jun 2012 17:35:36 -0400 > > From: jayare...@hotmail.com > > Subject: Re: Base registers > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > > > The problem is that all addresses are relative to something. > > Some are relative to a base register, some are relative > > to the current instruction. Even absolute addresses are > > relative to zero. ;-) > > > > How about base-free code? That sounds like a positive thing. > > > > (I avoided the temptation to to suggest "freebase" lest that > > be considered to have a negative connotation.) > > > > === > > > > > Date: Sun, 17 Jun 2012 17:13:30 -0400 > > > From: gt.ibm.li...@actionsoftware.com > > > Subject: Re: Base registers > > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > > > > > Why don't we "jump" to the underlying notion of the "jump" > instructions, > > > or more accurately "branch relative" instructions, which is relative > > > addressing: "relative address oriented programming". > > > > > > I'll admit that it's not concise, but I'm optimistic we won't have a > > > religious war about the resulting acronym. > > > > > > -- > > > > > > Regards, Gord Tomlin > > > Action Software International > > > (a division of Mazda Computer Corporation) > > > Tel: (905) 470-7113, Fax: (905) 470-6507 > > > > > > > > > On 2012-06-17 09:05, John Gilmore wrote: > > > > Words can of course have different specialized meanings in different > > > > contexts, but there is ordinarily an evolutionary path between these > > > > meanings. > > > > > > > > Physicians, for example, talk of "senile changes", meaning those > > > > associated with aging, in a way that is entirely devoid of pejorative > > > > intent. Or again, Chaucer and his contemporaries used the word > "lewd" > > > > to mean lay, not in holy orders; but there is a path between this > > > > meaning and the modern one: the clergy did not often make what we > call > > > > lewd gestures in public. > > > > > > > > I myself find 'baseless' very unsatisfactory, in part because it is > > > > not at all transparent. Thus, while I have no emotional investment > in > > > > the term "jump-based", I do believe a new one is needed; 'baseless' > > > > can scarcely avoid connotations of dispensability when in fact it is > > > > the base registers that are largely dispensable. > > > > > > > > We need to look forward to a time when the use of base registers, > > > > multiple ones in particular, and the arbitrary segmentation of code > > > > into 4096-byte pieces will be perceived as a quaint, historically > > > > interesting but obsolete practices; and a new contrasting term will > be > > > > helpful in changing the current "vulgar" mind set. (Mr Gilmartin's > > > > use of vulgar, which evolved from the Latin phrase "mobile vulgus", > is > > > > open to criticism; but that is a subject for another time and place.) > > > > > > > > Alternative suggestions? > > > > > > > > John Gilmore, Ashland, MA 01721 - USA > > > > > > > > > > > > -- OREXXMan
Re: Base registers
Sorry Steve. I didn't see your post until after I posted mine. === > Date: Sun, 17 Jun 2012 17:35:36 -0400 > From: jayare...@hotmail.com > Subject: Re: Base registers > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > The problem is that all addresses are relative to something. > Some are relative to a base register, some are relative > to the current instruction. Even absolute addresses are > relative to zero. ;-) > > How about base-free code? That sounds like a positive thing. > > (I avoided the temptation to to suggest "freebase" lest that > be considered to have a negative connotation.) > > === > > > Date: Sun, 17 Jun 2012 17:13:30 -0400 > > From: gt.ibm.li...@actionsoftware.com > > Subject: Re: Base registers > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > > > Why don't we "jump" to the underlying notion of the "jump" instructions, > > or more accurately "branch relative" instructions, which is relative > > addressing: "relative address oriented programming". > > > > I'll admit that it's not concise, but I'm optimistic we won't have a > > religious war about the resulting acronym. > > > > -- > > > > Regards, Gord Tomlin > > Action Software International > > (a division of Mazda Computer Corporation) > > Tel: (905) 470-7113, Fax: (905) 470-6507 > > > > > > On 2012-06-17 09:05, John Gilmore wrote: > > > Words can of course have different specialized meanings in different > > > contexts, but there is ordinarily an evolutionary path between these > > > meanings. > > > > > > Physicians, for example, talk of "senile changes", meaning those > > > associated with aging, in a way that is entirely devoid of pejorative > > > intent. Or again, Chaucer and his contemporaries used the word "lewd" > > > to mean lay, not in holy orders; but there is a path between this > > > meaning and the modern one: the clergy did not often make what we call > > > lewd gestures in public. > > > > > > I myself find 'baseless' very unsatisfactory, in part because it is > > > not at all transparent. Thus, while I have no emotional investment in > > > the term "jump-based", I do believe a new one is needed; 'baseless' > > > can scarcely avoid connotations of dispensability when in fact it is > > > the base registers that are largely dispensable. > > > > > > We need to look forward to a time when the use of base registers, > > > multiple ones in particular, and the arbitrary segmentation of code > > > into 4096-byte pieces will be perceived as a quaint, historically > > > interesting but obsolete practices; and a new contrasting term will be > > > helpful in changing the current "vulgar" mind set. (Mr Gilmartin's > > > use of vulgar, which evolved from the Latin phrase "mobile vulgus", is > > > open to criticism; but that is a subject for another time and place.) > > > > > > Alternative suggestions? > > > > > > John Gilmore, Ashland, MA 01721 - USA > > > > > > >
Re: Base registers
The problem is that all addresses are relative to something. Some are relative to a base register, some are relative to the current instruction. Even absolute addresses are relative to zero. ;-) How about base-free code? That sounds like a positive thing. (I avoided the temptation to to suggest "freebase" lest that be considered to have a negative connotation.) === > Date: Sun, 17 Jun 2012 17:13:30 -0400 > From: gt.ibm.li...@actionsoftware.com > Subject: Re: Base registers > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > Why don't we "jump" to the underlying notion of the "jump" instructions, > or more accurately "branch relative" instructions, which is relative > addressing: "relative address oriented programming". > > I'll admit that it's not concise, but I'm optimistic we won't have a > religious war about the resulting acronym. > > -- > > Regards, Gord Tomlin > Action Software International > (a division of Mazda Computer Corporation) > Tel: (905) 470-7113, Fax: (905) 470-6507 > > > On 2012-06-17 09:05, John Gilmore wrote: > > Words can of course have different specialized meanings in different > > contexts, but there is ordinarily an evolutionary path between these > > meanings. > > > > Physicians, for example, talk of "senile changes", meaning those > > associated with aging, in a way that is entirely devoid of pejorative > > intent. Or again, Chaucer and his contemporaries used the word "lewd" > > to mean lay, not in holy orders; but there is a path between this > > meaning and the modern one: the clergy did not often make what we call > > lewd gestures in public. > > > > I myself find 'baseless' very unsatisfactory, in part because it is > > not at all transparent. Thus, while I have no emotional investment in > > the term "jump-based", I do believe a new one is needed; 'baseless' > > can scarcely avoid connotations of dispensability when in fact it is > > the base registers that are largely dispensable. > > > > We need to look forward to a time when the use of base registers, > > multiple ones in particular, and the arbitrary segmentation of code > > into 4096-byte pieces will be perceived as a quaint, historically > > interesting but obsolete practices; and a new contrasting term will be > > helpful in changing the current "vulgar" mind set. (Mr Gilmartin's > > use of vulgar, which evolved from the Latin phrase "mobile vulgus", is > > open to criticism; but that is a subject for another time and place.) > > > > Alternative suggestions? > > > > John Gilmore, Ashland, MA 01721 - USA > > > >
Re: Base registers
On 6/17/2012 3:13 PM, Gord Tomlin wrote: Why don't we "jump" to the underlying notion of the "jump" instructions, or more accurately "branch relative" instructions, which is relative addressing: "relative address oriented programming". I'll admit that it's not concise, but I'm optimistic we won't have a religious war about the resulting acronym. You mean "Religious Argument Ontological Parsing"? :-) I was going to suggest 'free base' as a 'positive' way of saying one is relatively free from using base registers, but that term also has unfortunate conotations. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2012-06-17 09:05, John Gilmore wrote: Words can of course have different specialized meanings in different contexts, but there is ordinarily an evolutionary path between these meanings. Physicians, for example, talk of "senile changes", meaning those associated with aging, in a way that is entirely devoid of pejorative intent. Or again, Chaucer and his contemporaries used the word "lewd" to mean lay, not in holy orders; but there is a path between this meaning and the modern one: the clergy did not often make what we call lewd gestures in public. I myself find 'baseless' very unsatisfactory, in part because it is not at all transparent. Thus, while I have no emotional investment in the term "jump-based", I do believe a new one is needed; 'baseless' can scarcely avoid connotations of dispensability when in fact it is the base registers that are largely dispensable. We need to look forward to a time when the use of base registers, multiple ones in particular, and the arbitrary segmentation of code into 4096-byte pieces will be perceived as a quaint, historically interesting but obsolete practices; and a new contrasting term will be helpful in changing the current "vulgar" mind set. (Mr Gilmartin's use of vulgar, which evolved from the Latin phrase "mobile vulgus", is open to criticism; but that is a subject for another time and place.) Alternative suggestions? John Gilmore, Ashland, MA 01721 - USA -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html
Re: Base registers
Why don't we "jump" to the underlying notion of the "jump" instructions, or more accurately "branch relative" instructions, which is relative addressing: "relative address oriented programming". I'll admit that it's not concise, but I'm optimistic we won't have a religious war about the resulting acronym. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2012-06-17 09:05, John Gilmore wrote: Words can of course have different specialized meanings in different contexts, but there is ordinarily an evolutionary path between these meanings. Physicians, for example, talk of "senile changes", meaning those associated with aging, in a way that is entirely devoid of pejorative intent. Or again, Chaucer and his contemporaries used the word "lewd" to mean lay, not in holy orders; but there is a path between this meaning and the modern one: the clergy did not often make what we call lewd gestures in public. I myself find 'baseless' very unsatisfactory, in part because it is not at all transparent. Thus, while I have no emotional investment in the term "jump-based", I do believe a new one is needed; 'baseless' can scarcely avoid connotations of dispensability when in fact it is the base registers that are largely dispensable. We need to look forward to a time when the use of base registers, multiple ones in particular, and the arbitrary segmentation of code into 4096-byte pieces will be perceived as a quaint, historically interesting but obsolete practices; and a new contrasting term will be helpful in changing the current "vulgar" mind set. (Mr Gilmartin's use of vulgar, which evolved from the Latin phrase "mobile vulgus", is open to criticism; but that is a subject for another time and place.) Alternative suggestions? John Gilmore, Ashland, MA 01721 - USA
Re: Base registers
Unbased is better by a wide margin than baseless. I should still, however, prefer a non-negative form. John Gilmore, Ashland, MA 01721 - USA On 6/17/12, Gerhard Postpischil wrote: > On 6/17/2012 9:05 AM, John Gilmore wrote: >> Words can of course have different specialized meanings in different >> contexts, but there is ordinarily an evolutionary path between these >> meanings. > > My favorite along these lines is "stench", that did not always > mean unpleasant. I vividly remember a streetcar ride where > almost every passenger carried freshly cut lilacs, to the point > where the smell was overpowering, though not unpleasant. > >> Alternative suggestions? > > I used "unbased". > > Gerhard Postpischil > Bradford, VT >
Re: Base registers
On 6/17/2012 9:05 AM, John Gilmore wrote: Words can of course have different specialized meanings in different contexts, but there is ordinarily an evolutionary path between these meanings. My favorite along these lines is "stench", that did not always mean unpleasant. I vividly remember a streetcar ride where almost every passenger carried freshly cut lilacs, to the point where the smell was overpowering, though not unpleasant. Alternative suggestions? I used "unbased". Gerhard Postpischil Bradford, VT
Re: Jumpify Your Code (Was: Base registers)
On 6/17/2012 9:13 AM, Martin Truebner wrote: Ed, can I link to yours from mine? http://pi-sysprog.de/free/makerel.html or (in another language) http://pi-sysprog.de/free/makereld.html on the very end Of course! 8-) Your bilingual perspective (I mean VSE/MVS, not English/German ;-) ) is always highly appreciated! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Jumpify Your Code (Was: Base registers)
Ed, can I link to yours from mine? http://pi-sysprog.de/free/makerel.html or (in another language) http://pi-sysprog.de/free/makereld.html on the very end -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Jumpify Your Code (Was: Base registers)
On 6/16/2012 2:54 PM, Scott Ford wrote: I saw your 2007 presentation and have a copy. I am always looking for good examples to aid my education and understanding. For those having trouble finding the February 2011 version of this presentation on SHARE's new web site, here is a link to it on the Phoenix Software site: ftp://ftp.phoenixsoftware.com/pub/demo/Jumpify_Your_Code_2011.pdf -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Base registers
Words can of course have different specialized meanings in different contexts, but there is ordinarily an evolutionary path between these meanings. Physicians, for example, talk of "senile changes", meaning those associated with aging, in a way that is entirely devoid of pejorative intent. Or again, Chaucer and his contemporaries used the word "lewd" to mean lay, not in holy orders; but there is a path between this meaning and the modern one: the clergy did not often make what we call lewd gestures in public. I myself find 'baseless' very unsatisfactory, in part because it is not at all transparent. Thus, while I have no emotional investment in the term "jump-based", I do believe a new one is needed; 'baseless' can scarcely avoid connotations of dispensability when in fact it is the base registers that are largely dispensable. We need to look forward to a time when the use of base registers, multiple ones in particular, and the arbitrary segmentation of code into 4096-byte pieces will be perceived as a quaint, historically interesting but obsolete practices; and a new contrasting term will be helpful in changing the current "vulgar" mind set. (Mr Gilmartin's use of vulgar, which evolved from the Latin phrase "mobile vulgus", is open to criticism; but that is a subject for another time and place.) Alternative suggestions? John Gilmore, Ashland, MA 01721 - USA
Re: Base registers
On Jun 16, 2012, at 14:10, John Gilmore wrote: > 'Jumpify your code' suggests to me that we should perhaps replace > 'baseless', which in ordinary English means 'unfounded', with the > acronym JBC, for 'Jump-based code'. > No need. There are many instances where English accepts specialized meanings for words in special contexts which don't directly contradict each other, and of which some may even become pejorative. The first example that comes to my mind is "vulgar", as in "The vulgar meaning of 'baseless' is 'unfounded'." -- gil
Re: Base registers
Ed, I saw your 2007 presentation and have a copy. I am always looking for good examples to aid my education and understanding. Regards, Scott ford www.identityforge.com On Jun 15, 2012, at 8:36 PM, Edward Jaffe wrote: > On 6/5/2012 2:19 PM, Tom Marchant wrote: >> On Tue, 5 Jun 2012 15:59:36 -0400, Scott Ford wrote: >> >>> where can you find a good sample of baseless assembler code ? >> Look for Ed Jaffe's SHARE presentation "Jumpify your code". > > The original "jumpify your code" presentation was from 2007. When I updated it > in 2011 for zEnterprise, I retitled it "jumpify your programs". > > I *knew* I should have kept the original title! >:o > > -- > Edward E Jaffe > Phoenix Software International, Inc > 831 Parkview Drive North > El Segundo, CA 90245 > 310-338-0400 x318 > edja...@phoenixsoftware.com > http://www.phoenixsoftware.com/
Re: Base registers
'Jumpify your code' suggests to me that we should perhaps replace 'baseless', which in ordinary English means 'unfounded', with the acronym JBC, for 'Jump-based code'. John Gilmore, Ashland, MA 01721 - USA
Re: Base registers
John, Can't comment on VSE , we don't have any VSE customers, our customers are z/OS only. I not sure what ESL is, I assume it's a pricing plan from IBM for VSE, haven't worked VSE in yrs Scott ford www.identityforge.com On Jun 16, 2012, at 9:59 AM, John Gilmore wrote: > ISVs that have many VSE customers confront a special problem. If they > judge it morally and/or economically appropriate to continue to > support the ESL-trapped among these VSE customers they should do so by > providing two code paths. To do this is a trivial and inexpensive, > even in open code, as Tony Thigpen knows very well. > > I think that Edward Jaffe has this morning made the case for the use > of the new instructions about as well as it can be made; and I will > not therefore revisit it except to note that support for ARCH > ()-driven multiple code paths, which can be packaged up into > reusable macros readily (and could even be introduced into the > structured-programming macro package) is the appropriate resolution > of any need to support very different hardware groups concurrently; a > much better one than the systematic use of LCD technology that Tony, > if I have understood his views correctly, is advocating. > > John Gilmore, Ashland, MA 01721 - USA
Re: Base registers
ISVs that have many VSE customers confront a special problem. If they judge it morally and/or economically appropriate to continue to support the ESL-trapped among these VSE customers they should do so by providing two code paths. To do this is a trivial and inexpensive, even in open code, as Tony Thigpen knows very well. I think that Edward Jaffe has this morning made the case for the use of the new instructions about as well as it can be made; and I will not therefore revisit it except to note that support for ARCH ()-driven multiple code paths, which can be packaged up into reusable macros readily (and could even be introduced into the structured-programming macro package) is the appropriate resolution of any need to support very different hardware groups concurrently; a much better one than the systematic use of LCD technology that Tony, if I have understood his views correctly, is advocating. John Gilmore, Ashland, MA 01721 - USA
Re: Base registers
On 6/5/2012 2:19 PM, Tom Marchant wrote: On Tue, 5 Jun 2012 15:59:36 -0400, Scott Ford wrote: where can you find a good sample of baseless assembler code ? Look for Ed Jaffe's SHARE presentation "Jumpify your code". The original "jumpify your code" presentation was from 2007. When I updated it in 2011 for zEnterprise, I retitled it "jumpify your programs". I *knew* I should have kept the original title! >:o -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Base registers
On 6/2/2012 5:38 PM, Tony Thigpen wrote: > but there is none to be made for doing so in > writing even a new single RSECT. How about this reason. We have several customers running our software that are on pre-MP3000 machines that don't even support relative instructions. They still pay us for support and that includes software upgrades. Other vendors may not care about existing customers, but we do. Almost all of these customers also can't upgrade their VSE. They fell into the ESL trap with IBM many years ago and now can't get their budget dollars back to get current because of the IBM monthly charges. As faithful customers for many years, we do not want to kick them while they are down just so we can do 'fancier' code. There are two sides to this. You need to care about all of your customers, not just those with no money. Dragging premier customers, with the latest hardware and software, down to the level of the laggards is not fair to them. Customers that continue to invest heavily in the platform must be rewarded for doing so. IBM and ISV software should exploit the latest hardware and software features in ways that provide these leading edge customers with the very best performance and feature set possible lest they find an alternative (seemingly cheaper) way to host their applications. It's not just 'fancier' code. The productivity gains accrued by allowing programmers to leverage new facilities are immense; new features can be implemented in far less time giving customers more of they want for their maintenance dollars; tremendous run-time performance savings can be realized by leveraging new hardware and software features; today's memory rich (especially) 64-bit environments allow programs to do things only dreamed of twenty years ago; and, so on... The ESL problem is a unique problem for VSE that does not exist for MVS customers. Nevertheless, the reality is that very, Very, VERY few customers running severely back-level operating system releases are interested in installing the latest and greatest release of 'Product X' -- even on VSE. Often, such systems exist because the customer is in their 15th year of their 3-year plan to migrate off the mainframe. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Base registers
On Wed, 6 Jun 2012 20:57:47 +0200 Martin Truebner wrote: :>>> I suggest you learn how to use LOCTR. :>NO COMMENT It is good advice. :>>> It's a much simpler method than using :>=S() and certainly more readable. :>Simpler- maybe! more readable- judge it here: :> :>My suggestion: :>a SETC as intro :>and EX R2,=S(&PKA,QWORD,0(R10)) :>. :>or (more readable): :>a CODE LOCTR and DEFS LOCTR as intro :>and :>EX R2,PKA_02 :>DEFS LOCTR :>PKA_02 PKA QWORD,0(0,R10) :>CODE LOCTR I have a @DC macro as well as an @EX macro to allow the constants to be placed in the source file near the code that uses it and the assembler neatly packages all the constant data (including the EXed instructions) together. Isn't @EXR2,PKA,QSWORD,0(0,R10) clearer? -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies.
Re: Base registers
Let's not get in a spitting match. anyone can write bad code as an example of why someone else's style is bad. I am pretty sure I could write some pretty unintelligible code if I tried using any of the suggested methods. That doesn't mean a style is bad, it probably means I am not using it as intended. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Martin Truebner Sent: Wednesday, June 06, 2012 11:58 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base registers Jon, >> I suggest you learn how to use LOCTR. NO COMMENT >> It's a much simpler method than using =S() and certainly more readable. Simpler- maybe! more readable- judge it here: My suggestion: a SETC as intro and EX R2,=S(&PKA,QWORD,0(R10)) . or (more readable): a CODE LOCTR and DEFS LOCTR as intro and EX R2,PKA_02 DEFS LOCTR PKA_02 PKA QWORD,0(0,R10) CODE LOCTR plus the extra of inventing unique names .. I like the expression "in eyeball range" ;-) -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: Base registers
Jon, >> I suggest you learn how to use LOCTR. NO COMMENT >> It's a much simpler method than using =S() and certainly more readable. Simpler- maybe! more readable- judge it here: My suggestion: a SETC as intro and EX R2,=S(&PKA,QWORD,0(R10)) . or (more readable): a CODE LOCTR and DEFS LOCTR as intro and EX R2,PKA_02 DEFS LOCTR PKA_02 PKA QWORD,0(0,R10) CODE LOCTR plus the extra of inventing unique names .. I like the expression "in eyeball range" ;-) -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: Base registers
I suggest you learn how to use LOCTR. It's a much simpler method than using
=S() and certainly more readable. I'm not recommending in the way LOCTR was
used with DATA / CODE example although that is certainly one way.
My programs have the following in the program start macro (after the csect is
generated). &CSECT contains the CSECT name since &SYSECT and &SYSLOC are not set
when the CSECT is generated in the macro that generated the CSECT.
#EXLOCTR ,Execute instructions inserted with this location
counter
DS 0H Instructions must be halfword aligned
&CSECT LOCTR , Back to program
If you use the DATA / CODE method, then you will want this just before the CODE
LOCTR. I'm not suggesting you use this method but just in case you do.
Here is a sample call to my #EX macro below
#EX R2,'MVC SOURCE(0),DEST'
and it generates (length is checked where length was calculated)
BCTR R2,0Length relative to 0
EX R2,#EX_xxx Execute the instruction
LAR2,1(R2) Restore length (does not modify CC)
#EX LOCTR ,
#EX_xxx MVC SOURCE(0),DEST
MYPGM LOCTR , Back to program
Hope this helps, Jon.
.**
.* Desc: Execute instruction
.*
.* Copyright: 2010-2012 Jon Perryman
.*
.* Function:
.* Makes the length relative to 0 and executes the
.* specified instruction using the specified length.
.* The register is restored back to a length relative
.* to 1.
.*
.* Change log:
.* 2/12/2010 JPPCreated
.**
MACRO ,
&LABEL #EX &RELATIVE=1 Specify 0 if reg already rel=0
AIF ('&LABEL' EQ '').NOLABEL
&LABEL EQU *
.NOLABEL ANOP *
AIF ('&RELATIVE' EQ '0').LEN_OK1
BCTR &SYSLIST(1),0 Relative to 0
.LEN_OK1 ANOP ,
EX&SYSLIST(1),#EX_&SYSNDX
AIF ('&RELATIVE' EQ '0').LEN_OK2
LA&SYSLIST(1),1(&SYSLIST(1)) Relative to 1
.LEN_OK2 ANOP ,
&WORKSETC DEQUOTE('&SYSLIST(2)')
&WORKN SETA INDEX('&WORK',' ')
&WORK2 SETC '&WORK'(&WORKN+1,99)
&WORK2 SETC DCVAL('&WORK2')
&WORKSETC '&WORK'(1,&WORKN-1)
#EX LOCTR , Group #EX
#EX_&SYSNDX &WORK &WORK2
&SYSLOC LOCTR , Restore location counter
MEXIT ,
MEND ,
---
On Behalf Of Martin Truebner
Sent: Wednesday, June 06, 2012 11:46 AM
Subject: Re: Base registers
how is this (until EXRL is legalised ;-)
EX R2,=S(7*16+&PACK,DWORD,0(R10))
And Yes- I am aware of problems in the literalpool having
different usings
Re: Base registers
sigh been away from daily use of ASM. brain is starting to rot. which is bad as I am transitioning into doing CICS ASM. IBM Mainframe Assembler List wrote on 06/06/2012 01:15:54 PM: > From: "Watkins, Douglas" > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU, > Date: 06/06/2012 01:18 PM > Subject: Re: Base registers > Sent by: IBM Mainframe Assembler List > > Length of second operand is in R2, ORed with that of the first operand, > 7*16, when EX executes. > > > > http://www.compuware.com/ > The contents of this e-mail are intended for the named addressee > only. It contains information that may be confidential. Unless you > are the named addressee or an authorized designee, you may not copy > or use it, or disclose it to anyone else. If you received it in > error please notify us immediately and then destroy it. > > From: IBM Mainframe Assembler List > [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Kirk Talman > Sent: Wednesday, June 06, 2012 12:13 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base registers > > where is the length code for 0(r10) second operand? > >EX R2,=S(16*(7+16*(length_of_operand2-1)+&PACK,DWORD,0(R10)) > > IBM Mainframe Assembler List wrote on > 06/06/2012 11:46:07 AM: > > > From: Martin Truebner > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU, > > Date: 06/06/2012 11:52 AM > > Subject: Re: Base registers > > Sent by: IBM Mainframe Assembler List > > > > > Douglas, > > > > how is this (until EXRL is legalised ;-) > > > > EX R2,=S(7*16+&PACK,DWORD,0(R10)) > > > > And Yes- I am aware of problems in the literalpool having > > different usings > > > > - (for Robin) and I have verified that R2 is between F and 0 and > > that R10 is on the beginning of a string) > > -- > > Martin > > > > Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE > > more at http://www.picapcpu.de > > > - > 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. 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
Re: Base registers
Length of second operand is in R2, ORed with that of the first operand, 7*16, when EX executes. http://www.compuware.com/ The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Kirk Talman Sent: Wednesday, June 06, 2012 12:13 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base registers where is the length code for 0(r10) second operand? EX R2,=S(16*(7+16*(length_of_operand2-1)+&PACK,DWORD,0(R10)) IBM Mainframe Assembler List wrote on 06/06/2012 11:46:07 AM: > From: Martin Truebner > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU, > Date: 06/06/2012 11:52 AM > Subject: Re: Base registers > Sent by: IBM Mainframe Assembler List > > Douglas, > > how is this (until EXRL is legalised ;-) > > EX R2,=S(7*16+&PACK,DWORD,0(R10)) > > And Yes- I am aware of problems in the literalpool having > different usings > > - (for Robin) and I have verified that R2 is between F and 0 and > that R10 is on the beginning of a string) > -- > Martin > > Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE > more at http://www.picapcpu.de - 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. 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
Re: Base registers
Martin, Very clever! Personally, for everyday use, I prefer things a bit more "plain and simple." Though, I might consider creating a macro to incorporate such a technique: EXWOW R2,(PACK,DWORD,0(R10)) EXWOW R2,(MVC,DESTINATION_BUFFER,0(R10)) The latter being only marginally better than: EXR2,=S(&MVC,DESTINATION_BUFFER,0(R10)) Of course, one could simply locate the target instruction in with constant data that is assembled into program object, since that already has a base. I use LARL with EX because I like to keep the target in the vicinity of the code with which it belongs logically. I do like that your technique does keep the essential nature of the target very much within eyeball range. Doug http://www.compuware.com/ The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Martin Truebner Sent: Wednesday, June 06, 2012 11:46 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base registers Douglas, how is this (until EXRL is legalised ;-) EX R2,=S(7*16+&PACK,DWORD,0(R10)) And Yes- I am aware of problems in the literalpool having different usings - (for Robin) and I have verified that R2 is between F and 0 and that R10 is on the beginning of a string) -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: Base registers
where is the length code for 0(r10) second operand? EX R2,=S(16*(7+16*(length_of_operand2-1)+&PACK,DWORD,0(R10)) IBM Mainframe Assembler List wrote on 06/06/2012 11:46:07 AM: > From: Martin Truebner > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU, > Date: 06/06/2012 11:52 AM > Subject: Re: Base registers > Sent by: IBM Mainframe Assembler List > > Douglas, > > how is this (until EXRL is legalised ;-) > > EX R2,=S(7*16+&PACK,DWORD,0(R10)) > > And Yes- I am aware of problems in the literalpool having > different usings > > - (for Robin) and I have verified that R2 is between F and 0 and > that R10 is on the beginning of a string) > -- > Martin > > Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE > more at http://www.picapcpu.de - 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. 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
Re: Base registers
Douglas, how is this (until EXRL is legalised ;-) EX R2,=S(7*16+&PACK,DWORD,0(R10)) And Yes- I am aware of problems in the literalpool having different usings - (for Robin) and I have verified that R2 is between F and 0 and that R10 is on the beginning of a string) -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: Base registers
I had a feeling someone would point out that technicality, so... Let's not consider a temporarily-used-for-one-RX-instruction base register to be the same thing as a program-wide base register ;-) Also, a "baseless" program is less likely to be register-constrained; but, if it were, using "temp" R1 instead of, say R10, works just as well. http://www.compuware.com/ The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, June 06, 2012 11:02 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base registers On Jun 6, 2012, at 07:28, Watkins, Douglas wrote: > Here's one way to do standard EXecute without a base register: > > AHI R2,-1 Minus 1 for EX > *!not yetEXRL R2,_EX_MVC_OUTPUT (Move data to output buffer) > LARL R10,_EX_MVC_OUTPUT Move data to > EXR2,0(,R10) output buffer > Well, R10 looks like a base register to me. If you're critically register-constrained, this may be a problem. You could likewise do: AHI R2,-1 Minus 1 for EX BALR R10,0 EXR2,EX_MVC_OUTPUT-*(,R10) ... in fewer bytes of code (if I got it right). -- gil
Re: Base registers
> Still need test for negative. Very true -- unless, as is the case but not shown in the example below, I've already guaranteed R2 holds a value within my "safe range," which includes the maximum, too. http://www.compuware.com/ The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of robin Sent: Wednesday, June 06, 2012 11:19 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base registers From: Watkins, Douglas Sent: Wednesday, 6 June 2012 11:28 PM >Here's one way to do standard EXecute without a base register: > AHI R2,-1 Minus 1 for EX Still need test for negative. >*!not yetEXRL R2,_EX_MVC_OUTPUT (Move data to output buffer) > LARL R10,_EX_MVC_OUTPUT Move data to > EXR2,0(,R10) output buffer
Re: Base registers
From: Watkins, Douglas Sent: Wednesday, 6 June 2012 11:28 PM Here's one way to do standard EXecute without a base register: AHI R2,-1 Minus 1 for EX Still need test for negative. *!not yetEXRL R2,_EX_MVC_OUTPUT (Move data to output buffer) LARL R10,_EX_MVC_OUTPUT Move data to EXR2,0(,R10) output buffer
Re: Base registers
On Jun 6, 2012, at 07:28, Watkins, Douglas wrote: > Here's one way to do standard EXecute without a base register: > > AHI R2,-1 Minus 1 for EX > *!not yetEXRL R2,_EX_MVC_OUTPUT (Move data to output buffer) > LARL R10,_EX_MVC_OUTPUT Move data to > EXR2,0(,R10) output buffer > Well, R10 looks like a base register to me. If you're critically register-constrained, this may be a problem. You could likewise do: AHI R2,-1 Minus 1 for EX BALR R10,0 EXR2,EX_MVC_OUTPUT-*(,R10) ... in fewer bytes of code (if I got it right). -- gil
Re: Base registers
Here's one way to do standard EXecute without a base register:
AHI R2,-1 Minus 1 for EX
*!not yetEXRL R2,_EX_MVC_OUTPUT (Move data to output buffer)
LARL R10,_EX_MVC_OUTPUT Move data to
EXR2,0(,R10) output buffer
I believe, for most applications, "baseless" code is the way to go
moving forward when writing new code or refactoring existing code. Of
course, required are bases for save area/local stack and
constants/LTORG. A program manages bases for other data areas, just as
always -- passed-in-by-reference parameters, heap storage, control
blocks, I/O buffers, et cetera. Changing B-s to J-s, BCT to BRCT, et
cetera, is tedious but simple ("change all"). One may encounter macros
(IBM and otherwise) in existing code that, as traditionally used, have
required a base -- there are ways to deal with those.
All in all, I've found this entails a relatively small learning curve
and amount of effort and cures one of the greatest headaches associated
with assembler coding.
Doug Watkins
http://www.compuware.com/
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it.
From: IBM Mainframe Assembler List
[mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Tom Marchant
Sent: Tuesday, June 05, 2012 5:20 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base registers
On Tue, 5 Jun 2012 15:59:36 -0400, Scott Ford wrote:
>where can you find a good sample of baseless assembler code ?
Look for Ed Jaffe's SHARE presentation "Jumpify your code".
"Baseless" is not an accurate description, IMO. You still need
base registers to reference data. You can, however, use very few
base registers for your code simply by using relative branches
("jump"). There are one or two exceptions, depending upon your
hardware. One is that there is no indexed relative branch. It's
hard for me to imagine what such a thing would do anyway. The
other is that EXRL was introduced (IIRC) on the z10. The standard
EXecute instruction requires a base register.
--
Tom Marchant
Re: Base registers
That should be some codedidnt say my eyes and fingers werent old ...
Scott J Ford
Software Engineer
http://www.identityforge.com
From: Scott Ford
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Sent: Tuesday, June 5, 2012 5:23 PM
Subject: Re: Base registers
Tom,
Thank you, I have his great presentation and John gave me so code, and who said
we old folks cant change
Scott J Ford
Software Engineer
http://www.identityforge.com
From: Tom Marchant
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Sent: Tuesday, June 5, 2012 5:19 PM
Subject: Re: Base registers
On Tue, 5 Jun 2012 15:59:36 -0400, Scott Ford wrote:
>where can you find a good sample of baseless assembler code ?
Look for Ed Jaffe's SHARE presentation "Jumpify your code".
"Baseless" is not an accurate description, IMO. You still need
base registers to reference data. You can, however, use very few
base registers for your code simply by using relative branches
("jump"). There are one or two exceptions, depending upon your
hardware. One is that there is no indexed relative branch. It's
hard for me to imagine what such a thing would do anyway. The
other is that EXRL was introduced (IIRC) on the z10. The standard
EXecute instruction requires a base register.
--
Tom Marchant
Re: Base registers
Tom,
Thank you, I have his great presentation and John gave me so code, and who said
we old folks cant change
Scott J Ford
Software Engineer
http://www.identityforge.com
From: Tom Marchant
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Sent: Tuesday, June 5, 2012 5:19 PM
Subject: Re: Base registers
On Tue, 5 Jun 2012 15:59:36 -0400, Scott Ford wrote:
>where can you find a good sample of baseless assembler code ?
Look for Ed Jaffe's SHARE presentation "Jumpify your code".
"Baseless" is not an accurate description, IMO. You still need
base registers to reference data. You can, however, use very few
base registers for your code simply by using relative branches
("jump"). There are one or two exceptions, depending upon your
hardware. One is that there is no indexed relative branch. It's
hard for me to imagine what such a thing would do anyway. The
other is that EXRL was introduced (IIRC) on the z10. The standard
EXecute instruction requires a base register.
--
Tom Marchant
Re: Base registers
On Tue, 5 Jun 2012 15:59:36 -0400, Scott Ford wrote:
>where can you find a good sample of baseless assembler code ?
Look for Ed Jaffe's SHARE presentation "Jumpify your code".
"Baseless" is not an accurate description, IMO. You still need
base registers to reference data. You can, however, use very few
base registers for your code simply by using relative branches
("jump"). There are one or two exceptions, depending upon your
hardware. One is that there is no indexed relative branch. It's
hard for me to imagine what such a thing would do anyway. The
other is that EXRL was introduced (IIRC) on the z10. The standard
EXecute instruction requires a base register.
--
Tom Marchant
Re: Base registers
Damn, you had to include the word "good". If you want some baseless code which is LE enabled and is designed to run as a z/OS UNIX command, you can download my UNIX "alpha" code from the CBT. It is FILE864 at http://www.cbttape.org/updates.htm I also attached a non-LE baseless HLASM program source code to this email. It is a do nothing skeleton. I think the listserv will strip it out. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -Original Message- > From: IBM Mainframe Assembler List > [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Scott Ford > Sent: Tuesday, June 05, 2012 3:00 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base registers > > Guys, > > John and spoke where can you find a good sample of baseless > assembler code ? > I want to convert some of ours , need a sample to get me > started, it would help... > > Scott ford > www.identityforge.com > > On Jun 5, 2012, at 2:51 PM, "Robert A. Rosenberg" > wrote: > > > At 07:57 -0400 on 06/05/2012, Tom Marchant wrote about Re: > Base registers: > > > >> Yuck. By adding a few LOCTR instructions, all of the data > can be grouped at > >> the beginning of the program. If relative branches are > used in the code, > >> the base register is needed only for data and literals. > >> > >> MYCSECT CSECT > >> USING *,R15 > >> J BYID > >> DATA LOCTR > >> ID DCC'module-name' > >> BASESDCA(MYCSECT) > >> DCA(MYCSECT+4096) > >> DCA(MYCSECT+2*4096) > >> DCA(MYCSECT+3*4096) > >> BYID DS0H > >> CODE LOCTR > >> LMR9,R12,BASES > >> DROP R15 > >> USING MYCSECT,R9,R10,R11,R12 > >> ... > >> DATA LOCTR > >> * additional DC statements are coded here > >> LTORG > >> > >> You can probably do with only one base register for the data. > > > > That BYID needs to be placed after the CODE LOCTR or you will be > > jumping into your DATA area and a DC or the LTORG. > >
Re: Base registers
On Tue, 5 Jun 2012 14:51:48 -0400, Robert A. Rosenberg wrote: >At 07:57 -0400 on 06/05/2012, Tom Marchant wrote about Re: Base registers: > >>By adding a few LOCTR instructions, all of the data can be grouped at >>the beginning of the program. If relative branches are used in the code, >>the base register is needed only for data and literals. >> >>MYCSECT CSECT >> USING *,R15 >> J BYID >>DATA LOCTR >>ID DCC'module-name' >>BASESDCA(MYCSECT) >> DCA(MYCSECT+4096) >> DCA(MYCSECT+2*4096) >> DCA(MYCSECT+3*4096) >>BYID DS0H >>CODE LOCTR >> LMR9,R12,BASES >> DROP R15 >> USING MYCSECT,R9,R10,R11,R12 >>... >>DATA LOCTR >>* additional DC statements are coded here >> LTORG >> >>You can probably do with only one base register for the data. > >That BYID needs to be placed after the CODE LOCTR or you will be >jumping into your DATA area and a DC or the LTORG. Right. Thanks for the correction. The above should be coded as: >>MYCSECT CSECT >> USING *,R15 >> J BYID >>DATA LOCTR >>ID DCC'module-name' >>BASESDCA(MYCSECT) >> DCA(MYCSECT+4096) >> DCA(MYCSECT+2*4096) >> DCA(MYCSECT+3*4096) >>CODE LOCTR >>BYID DS0H >> LMR9,R12,BASES >> DROP R15 >> USING MYCSECT,R9,R10,R11,R12 >>... >>DATA LOCTR >>* additional DC statements are coded here >> LTORG -- Tom Marchant
Re: Base registers
Guys, John and spoke where can you find a good sample of baseless assembler code ? I want to convert some of ours , need a sample to get me started, it would help... Scott ford www.identityforge.com On Jun 5, 2012, at 2:51 PM, "Robert A. Rosenberg" wrote: > At 07:57 -0400 on 06/05/2012, Tom Marchant wrote about Re: Base registers: > >> Yuck. By adding a few LOCTR instructions, all of the data can be grouped at >> the beginning of the program. If relative branches are used in the code, >> the base register is needed only for data and literals. >> >> MYCSECT CSECT >> USING *,R15 >> J BYID >> DATA LOCTR >> ID DCC'module-name' >> BASESDCA(MYCSECT) >> DCA(MYCSECT+4096) >> DCA(MYCSECT+2*4096) >> DCA(MYCSECT+3*4096) >> BYID DS0H >> CODE LOCTR >> LMR9,R12,BASES >> DROP R15 >> USING MYCSECT,R9,R10,R11,R12 >> ... >> DATA LOCTR >> * additional DC statements are coded here >> LTORG >> >> You can probably do with only one base register for the data. > > That BYID needs to be placed after the CODE LOCTR or you will be > jumping into your DATA area and a DC or the LTORG.
Re: Base registers
At 07:57 -0400 on 06/05/2012, Tom Marchant wrote about Re: Base registers: Yuck. By adding a few LOCTR instructions, all of the data can be grouped at the beginning of the program. If relative branches are used in the code, the base register is needed only for data and literals. MYCSECT CSECT USING *,R15 J BYID DATA LOCTR ID DCC'module-name' BASESDCA(MYCSECT) DCA(MYCSECT+4096) DCA(MYCSECT+2*4096) DCA(MYCSECT+3*4096) BYID DS0H CODE LOCTR LMR9,R12,BASES DROP R15 USING MYCSECT,R9,R10,R11,R12 ... DATA LOCTR * additional DC statements are coded here LTORG You can probably do with only one base register for the data. That BYID needs to be placed after the CODE LOCTR or you will be jumping into your DATA area and a DC or the LTORG.
Re: Base registers
Use R14 instead of R1 to avoid the reloading of R1 (parameter list pointer). We always set the new save are to all X'FF' so it stands out in a DUMP. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of McKown, John Sent: Tuesday, June 05, 2012 7:18 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base registers OOPS, the statement: AROUND DS 0H should be before the ST R13,4(,R1) -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -Original Message- > From: IBM Mainframe Assembler List > [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of McKown, John > Sent: Tuesday, June 05, 2012 7:08 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base registers > > > -Original Message- > > From: IBM Mainframe Assembler List > > [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Robert > > A. Rosenberg > > Sent: Monday, June 04, 2012 11:33 PM > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > Subject: Re: Base registers > > > > > > > By replacing the MYCSECT references with BYID+4 you can pick up some > > extra free addressability (at the expense of having the offsets > > non-zero based). > > > Back long ago, before I started writing "pure" or "reentrant" > code, I would always start my routines: > > MYCSECT CSECT > USING *,R15 > SAVE (14,12),,* > BAL R1,AROUND > SAVEAREA DC 18A(0) > ST R13,4(,R1) > ST R1,8(,R13) > LR R13,R1 > DROP R15 > USING SAVEAREA,R13 > L R1,4(,R13) > L R1,20(,R1) RESTORE ORIGINAL R1 > ... > > I don't do this any more, in most cases. Just to horrify some > of you, I now generally code HLASM enabled code, using all > the CEExxx macros. > > === > > A reason that my manager did not like the above was that if > the base register points to the beginning of the CSECT, and > you use the SAVE macro properly, you can look at the storage > pointed to by the base register to see the "eyecatcher" of > the program which abended. The SAVE would usually look something like: > > SAVE (14,12),,'&SYSECT &SYSCLOCK' > > And he always used base registers in reverse order: R12, R11, > R10, and so on. > > > -- > John McKown > Systems Engineer IV > IT > > Administrative Services Group > > HealthMarkets(r) > > 9151 Boulevard 26 * N. Richland Hills * TX 76010 > (817) 255-3225 phone * > john.mck...@healthmarkets.com * www.HealthMarkets.com > > Confidentiality Notice: This e-mail message may contain > confidential or proprietary information. If you are not the > intended recipient, please contact the sender by reply e-mail > and destroy all copies of the original message. > HealthMarkets(r) is the brand name for products underwritten > and issued by the insurance subsidiaries of HealthMarkets, > Inc. -The Chesapeake Life Insurance Company(r), Mid-West > National Life Insurance Company of TennesseeSM and The MEGA > Life and Health Insurance Company.SM > >
Re: Base registers
OOPS, the statement: AROUND DS 0H should be before the ST R13,4(,R1) -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -Original Message- > From: IBM Mainframe Assembler List > [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of McKown, John > Sent: Tuesday, June 05, 2012 7:08 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base registers > > > -Original Message- > > From: IBM Mainframe Assembler List > > [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Robert > > A. Rosenberg > > Sent: Monday, June 04, 2012 11:33 PM > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > Subject: Re: Base registers > > > > > > > By replacing the MYCSECT references with BYID+4 you can pick up some > > extra free addressability (at the expense of having the offsets > > non-zero based). > > > Back long ago, before I started writing "pure" or "reentrant" > code, I would always start my routines: > > MYCSECT CSECT > USING *,R15 > SAVE (14,12),,* > BAL R1,AROUND > SAVEAREA DC 18A(0) > ST R13,4(,R1) > ST R1,8(,R13) > LR R13,R1 > DROP R15 > USING SAVEAREA,R13 > L R1,4(,R13) > L R1,20(,R1) RESTORE ORIGINAL R1 > ... > > I don't do this any more, in most cases. Just to horrify some > of you, I now generally code HLASM enabled code, using all > the CEExxx macros. > > === > > A reason that my manager did not like the above was that if > the base register points to the beginning of the CSECT, and > you use the SAVE macro properly, you can look at the storage > pointed to by the base register to see the "eyecatcher" of > the program which abended. The SAVE would usually look something like: > > SAVE (14,12),,'&SYSECT &SYSCLOCK' > > And he always used base registers in reverse order: R12, R11, > R10, and so on. > > > -- > John McKown > Systems Engineer IV > IT > > Administrative Services Group > > HealthMarkets(r) > > 9151 Boulevard 26 * N. Richland Hills * TX 76010 > (817) 255-3225 phone * > john.mck...@healthmarkets.com * www.HealthMarkets.com > > Confidentiality Notice: This e-mail message may contain > confidential or proprietary information. If you are not the > intended recipient, please contact the sender by reply e-mail > and destroy all copies of the original message. > HealthMarkets(r) is the brand name for products underwritten > and issued by the insurance subsidiaries of HealthMarkets, > Inc. -The Chesapeake Life Insurance Company(r), Mid-West > National Life Insurance Company of TennesseeSM and The MEGA > Life and Health Insurance Company.SM > >
Re: Base registers
> -Original Message- > From: IBM Mainframe Assembler List > [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Robert > A. Rosenberg > Sent: Monday, June 04, 2012 11:33 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base registers > > > By replacing the MYCSECT references with BYID+4 you can pick up some > extra free addressability (at the expense of having the offsets > non-zero based). > Back long ago, before I started writing "pure" or "reentrant" code, I would always start my routines: MYCSECT CSECT USING *,R15 SAVE (14,12),,* BAL R1,AROUND SAVEAREA DC 18A(0) ST R13,4(,R1) ST R1,8(,R13) LR R13,R1 DROP R15 USING SAVEAREA,R13 L R1,4(,R13) L R1,20(,R1) RESTORE ORIGINAL R1 ... I don't do this any more, in most cases. Just to horrify some of you, I now generally code HLASM enabled code, using all the CEExxx macros. === A reason that my manager did not like the above was that if the base register points to the beginning of the CSECT, and you use the SAVE macro properly, you can look at the storage pointed to by the base register to see the "eyecatcher" of the program which abended. The SAVE would usually look something like: SAVE (14,12),,'&SYSECT &SYSCLOCK' And he always used base registers in reverse order: R12, R11, R10, and so on. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Re: Base registers
On Tue, 5 Jun 2012 00:32:32 -0400, Robert A. Rosenberg wrote: >At 18:44 + on 06/04/2012, Bodoh John Robert wrote about Re: Base registers: > >>MYCSECT CSECT >> USING *,R15 >> B BYID >>ID DCC'module-name' >>BASESDCA(MYCSECT) >> DCA(MYCSECT+4096) >> DCA(MYCSECT+2*4096) >> DCA(MYCSECT+3*4096) >>BYID DS0H >> LMR9,R12,BASES >> DROP R15 >> USING MYCSECT,R9,R10,R11,R12 >> >>One CPU instruction to load all base registers. I don't really like >>dealing with such large programs but I can't do anything about it so >>I'll support it the way it it. >> >>John > >By replacing the MYCSECT references with BYID+4 you can pick up some >extra free addressability (at the expense of having the offsets >non-zero based). Yuck. By adding a few LOCTR instructions, all of the data can be grouped at the beginning of the program. If relative branches are used in the code, the base register is needed only for data and literals. MYCSECT CSECT USING *,R15 J BYID DATA LOCTR ID DCC'module-name' BASESDCA(MYCSECT) DCA(MYCSECT+4096) DCA(MYCSECT+2*4096) DCA(MYCSECT+3*4096) BYID DS0H CODE LOCTR LMR9,R12,BASES DROP R15 USING MYCSECT,R9,R10,R11,R12 ... DATA LOCTR * additional DC statements are coded here LTORG You can probably do with only one base register for the data. -- Tom Marchant
Re: Base registers
At 18:44 + on 06/04/2012, Bodoh John Robert wrote about Re: Base registers: The code we use here at my job usually has very large modules and used several base registers. I have seen the following technique used: MYCSECT CSECT USING *,R15 B BYID ID DCC'module-name' BASESDCA(MYCSECT) DCA(MYCSECT+4096) DCA(MYCSECT+2*4096) DCA(MYCSECT+3*4096) BYID DS0H LMR9,R12,BASES DROP R15 USING MYCSECT,R9,R10,R11,R12 One CPU instruction to load all base registers. I don't really like dealing with such large programs but I can't do anything about it so I'll support it the way it it. John By replacing the MYCSECT references with BYID+4 you can pick up some extra free addressability (at the expense of having the offsets non-zero based).
Re: Automatic reply: Base registers
Can IT be Trusted on Personal Devices (Nos 9,16,41,50). --Original Message-- From: Scott, Samuel J Sender: IBM Mainframe Assembler List To: IBM Mainframe Assembler List ReplyTo: IBM Mainframe Assembler List Subject: Automatic reply: Base registers Sent: Jun 4, 2012 09:05 I will be out of the office 6/3 thru 6/11. If you need assistance please call Don Neaves at 817-252-8188 or Darrell Thompson at 817-252-8961. Thanks! Sent via BlackBerry from T-Mobile
Re: Base registers
The code we use here at my job usually has very large modules and used several base registers. I have seen the following technique used: MYCSECT CSECT USING *,R15 B BYID ID DCC'module-name' BASESDCA(MYCSECT) DCA(MYCSECT+4096) DCA(MYCSECT+2*4096) DCA(MYCSECT+3*4096) BYID DS0H LMR9,R12,BASES DROP R15 USING MYCSECT,R9,R10,R11,R12 One CPU instruction to load all base registers. I don't really like dealing with such large programs but I can't do anything about it so I'll support it the way it it. John
Re: Base registers
Bill, Amen, I first wrong BAL on a 360/20, didn't have the 1401 exposure ..man half words were real important Scott ford www.identityforge.com On Jun 4, 2012, at 11:15 AM, Bill Fairchild wrote: > I have seen many old IBM modules (in dumps, microfiche, etc.) in which the > first few instructions are something like this: > MODULE USING *,R15 >LRR12,R15 >LA R11,4095(,R12) >DROP R15 >USING MODULE,R12 >USING MODULE+4095,R11 > This allows 8,191 bytes of local addressability to be established with only > two instructions for a total length of 6 bytes of executable code. This kind > of code was "state of the art" long ago when each additional byte of storage > was vastly more expensive than that same additional byte is today. Back in > those days there was no real storage or virtual storage, just "storage", and > modules had to be as small as possible. And many modules written way back > then are still alive and well inside z/whatever-its-latest-name-is. > Yes, the odd offsets look weird, but the weird look does not prevent the > DAT's ability to add the base register's contents to the displacement and > generate the correct address. > When one is writing new code, one is free to be elitist and exploit the > latest and greatest instructions that are available on the processors on > which the code is expected to run. > When one is working with old code, or even new code written by Luddites, > denigrating the technology used does not really help in understanding what > the module is doing. > > Bill Fairchild > Programmer > Rocket Software > 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA > t: +1.617.614.4503 * e: bfairch...@rocketsoftware.com * w: > www.rocketsoftware.com > > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of robin > Sent: Sunday, June 03, 2012 7:45 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base registers > > From: Chuck Arney > Sent: Sunday, 3 June 2012 6:53 AM > >> I don't think you really want your base register pointing to an odd address. >> You need to add 1 more to make it right and that requires another >> instruction. > > There's no need to be scared of an odd value. > It is, after all, the assembler that calculates displacements.
Re: Base registers
I have seen many old IBM modules (in dumps, microfiche, etc.) in which the first few instructions are something like this: MODULE USING *,R15 LRR12,R15 LA R11,4095(,R12) DROP R15 USING MODULE,R12 USING MODULE+4095,R11 This allows 8,191 bytes of local addressability to be established with only two instructions for a total length of 6 bytes of executable code. This kind of code was "state of the art" long ago when each additional byte of storage was vastly more expensive than that same additional byte is today. Back in those days there was no real storage or virtual storage, just "storage", and modules had to be as small as possible. And many modules written way back then are still alive and well inside z/whatever-its-latest-name-is. Yes, the odd offsets look weird, but the weird look does not prevent the DAT's ability to add the base register's contents to the displacement and generate the correct address. When one is writing new code, one is free to be elitist and exploit the latest and greatest instructions that are available on the processors on which the code is expected to run. When one is working with old code, or even new code written by Luddites, denigrating the technology used does not really help in understanding what the module is doing. Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: bfairch...@rocketsoftware.com * w: www.rocketsoftware.com -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of robin Sent: Sunday, June 03, 2012 7:45 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base registers From: Chuck Arney Sent: Sunday, 3 June 2012 6:53 AM >I don't think you really want your base register pointing to an odd address. >You need to add 1 more to make it right and that requires another >instruction. There's no need to be scared of an odd value. It is, after all, the assembler that calculates displacements.
Re: Base registers
Thanks Gerhard, I feel the same way, especially when you work for a small company and your the only one writing Assembler, with customers asking for changes Scott ford www.identityforge.com On Jun 4, 2012, at 2:49 AM, Gerhard Postpischil wrote: > On 6/3/2012 8:52 AM, John Gilmore wrote: >> Gerhard's point is not so easily dismissed; but 1) it is >> self-defeating for the technology if pushed very far: it freezes >> software in a posture that is now more than fifteen years behind the >> state of the art; and 2) the market for even moderately-priced >> software among MVT-using hobbyists is very small. Still, seriously >> pursued dual-path software is is certainly viable. > > Supporting obsolete systems is a labor of love; I see no reason > to impute financial objectives to their support. For example, > Dave Cole has offered the MVS version of XDC for free, except no > copy of this version of it has been found. > >> As a now certified élitist, I am nevertheless unrepentent. Urgings >> about compatibility requirements and the like usually hide Luddite >> impulses, reluctance to accommodate the (not very) new, which account >> for a good many of the troubles that the mainframe community is >> experiencing. > > If I were responsible for a Fortune 500 company, I would be > leery of making changes solely to avoid consideration as a > Luddite. And for a mission critical business application, I > certainly would prefer a machine optimized compiler over > assembler (programmers should provide global optimization). > > My approach is pragmatic - use the appropriate tools best suited > for the task at hand. If that means consciously deciding on old > code reuse rather than new development, that may prove faster > and cheaper in the long run. But I agree that old code should > not be used simply because a programmer is not up to speed on > new features. > > Gerhard Postpischil > Bradford, VT
Re: Base registers
That was a typo, opinionsour customers usually dictate needs many times Scott ford www.identityforge.com On Jun 4, 2012, at 9:00 AM, Scott Ford wrote: > Martin, > > As the say options are like ...everyone had one...your entitled to yours > > Scott ford > www.identityforge.com > > On Jun 4, 2012, at 8:27 AM, Martin Truebner wrote: > >> Tony, >> > I have yet to find that VSE-customer that pays for Vendor-software and >>> has no money for hardware or operating-system-software AND demands >>> new features. >> We have several that meet this requirement. Think about the VSE 2.6 on >> P390 ESL boxes. >> >> I can imagine customers running that- but asking for new features? >> >> This is like asking for an aircondition in a Ford T. >> >> -- >> Martin >> >> Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE >> more at http://www.picapcpu.de
Automatic reply: Base registers
I will be out of the office 6/3 thru 6/11. If you need assistance please call Don Neaves at 817-252-8188 or Darrell Thompson at 817-252-8961. Thanks!
Re: Base registers
Martin, As the say options are like ...everyone had one...your entitled to yours Scott ford www.identityforge.com On Jun 4, 2012, at 8:27 AM, Martin Truebner wrote: > Tony, > I have yet to find that VSE-customer that pays for Vendor-software and >> has no money for hardware or operating-system-software AND demands >> new features. > We have several that meet this requirement. Think about the VSE 2.6 on > P390 ESL boxes. > > I can imagine customers running that- but asking for new features? > > This is like asking for an aircondition in a Ford T. > > -- > Martin > > Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE > more at http://www.picapcpu.de
Re: Base registers
Tony, >> > I have yet to find that VSE-customer that pays for Vendor-software and > has no money for hardware or operating-system-software AND demands > new features. We have several that meet this requirement. Think about the VSE 2.6 on P390 ESL boxes. I can imagine customers running that- but asking for new features? This is like asking for an aircondition in a Ford T. -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: Base registers
I think it may have been an parody of a joke:
Question: "How much money is enough?"
Answer: "Just a little bit more."
In assembler, it is "how many bytes do you need to be resolvable to a valid
offset?" "just a few more."
It's why I (as a customer only), love doing "baseless" programming. I separate
the code and data sections, using a base register only for the data section. I
load the base register using an LAY (if contained in the same CSECT). I now
also use "pure" coding techniques. In this case "pure" means that I never store
into the CSECT itself. Actually, I use an RSECT. This is a requirement for
writing DLLs in HLASM. Which I have successfully done ("beause I can").
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or
proprietary information. If you are not the intended recipient, please contact
the sender by reply e-mail and destroy all copies of the original message.
HealthMarkets(r) is the brand name for products underwritten and issued by the
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The
MEGA Life and Health Insurance Company.SM
> -Original Message-
> From: IBM Mainframe Assembler List
> [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of robin
> Sent: Monday, June 04, 2012 5:20 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Base registers
>
> From: Rob van der Heij
> Sent: Monday, 4 June 2012 4:41 PM
>
> On Mon, Jun 4, 2012 at 2:45 AM, robin wrote:
>
> >> There's no need to be scared of an odd value.
> >> It is, after all, the assembler that calculates displacements.
> >> If it bothers you, make it 4092. Still no extra
> instruction needed.
>
> >Since most of the time you just new a few more bytes anyway ;-)
>
> Even with the nonsense word changed a la Martin,
> your response still doesn't make sense.
>
>
