AW: Re: How to separate instructions and data generated in macro?
> When a program is running, it has a 72 byte R13 area that is "ready" to > be used by a called program/routine. During the 'current' program, this > area is unused and available If I have a macro that needs a little work > area, I just use something like: Yep, I just used this in the solution to my "hook into LE modules" problem I posted about recently. I wanted to allocate a workarea at first use and anchor it in a name/token pair. To find out if this is the first time I'm getting control, I needed to see if my name/token pair existed. Infortunately, the IEANTRT service needs some storage (Peter RElson posted that there will be a register only inface with z/OS 2.2). I was using the caller's save are for this. -- Peter Hunkeler
Re: AW: Re: How to separate instructions and data generated in macro?
Peter, I think I was unclear with my post. When a program is running, it has a 72 byte R13 area that is "ready" to be used by a called program/routine. During the 'current' program, this area is unused and available If I have a macro that needs a little work area, I just use something like: ST Rx,8(,R13) code L Rx,8(,R13) No GETMAIN/FREEMAIN involved. It's 64 free bytes to use anytime, just don't expect it to survive outside your macro. (And don't use bytes 0-7.) Tony Thigpen Peter Hunkeler wrote on 01/15/2017 01:29 PM: I sure have useing one GETMAIN/STORAGE OBTAIN to allocate storage for the new save area as well as the workarea for the code as long as I can remember (I do admit, however, that I cannot remember how far back I can remember ). Anyway I think this is pretty much standard coding for reentrant code. -- Peter Hunkeler
Re: How to separate instructions and data generated in macro?
> You are generating a WTO MF=L inline? You have your macro, and as part of > its expansion, it generates both a WTO MF=L and a WTO MF=E, all in-line? Yes. -- Peter Hunkeler
Re: How to separate instructions and data generated in macro?
You are generating a WTO MF=L inline? You have your macro, and as part of its expansion, it generates both a WTO MF=L and a WTO MF=E, all in-line? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Peter Hunkeler Sent: Sunday, January 15, 2017 10:13 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: How to separate instructions and data generated in macro? >Depending on how complex the generated data is it might be possible to -- Peter Hunkeler >generate it as a literal. The location of literal data is always somewhat >separate from machine instructions and easy to control with LTORG and LOCTR. No, literals are not an option since the macro is generating WTO MF=L macros. -- Peter Hunkeler
AW: Re: How to separate instructions and data generated in macro?
> Extend the save area. Some have criticized even that practice. > I don't understand why. Some prejudice that R13 should not be > used as a work area base? I sure have useing one GETMAIN/STORAGE OBTAIN to allocate storage for the new save area as well as the workarea for the code as long as I can remember (I do admit, however, that I cannot remember how far back I can remember ). Anyway I think this is pretty much standard coding for reentrant code. -- Peter Hunkeler
AW: Re: How to separate instructions and data generated in macro?
> LOCTR is your friend. I had a look at LOCTR before posting. A possible drawback of LOCTR the macro's LOCTR might not be the last one in the CSECT. The static data the macro generates might lead other data in later LOCTR sections to be moved out of the USING range. I cannot control the macro's LOCTR will the last one in any case. Sure, it is not a problem to tell the user about this fact in the macro descriptin, so he/she can make sure other LOCTRs are started before the first invocation of my macro. I was just looking if there is a failsafe way to achieve what I want. An own CSECT would have been, but I inderstand the drawbacks of unnamed CSECT, mostly imortant in the context of SMP/E. Although I do not expect the macro to be used in an SMP/E context, but you never know. I'll got the LOCTR way, and will add a corresponding comment. -- Peter Hunkeler
AW: Re: How to separate instructions and data generated in macro?
> And of course the traditional solution to this problem is MF=E/MF=L variants of the macro. Apart from using as part of the code, I often use the macro as part of debugging or as testin aid, to quickly display registers or variable data. This is why I'd like to keep it's usage as simple as possible. The macro is generating the WTO MF=L and WTO MF=(E...) as well as the code to move that the MF=L list to a workarea for the code to be reeentrant. -- Peter Hunkeler
Re: How to separate instructions and data generated in macro?
>Depending on how complex the generated data is it might be possible to -- Peter Hunkeler >generate it as a literal. The location of literal data is always somewhat >separate from machine instructions and easy to control with LTORG and LOCTR. No, literals are not an option since the macro is generating WTO MF=L macros. -- Peter Hunkeler
AW: Re: How to separate instructions and data generated in macro?
>If you accept GOFF, of course each data CSECT can be named as the >parent CSECT with a distinctive suffix. E.g.: CODESECT.WtoText. >SMP/E is hostile to long names as ++MOD element names but friendly >to them in the CSECT() option. > >What's wrong with GOFF? > >-- gil Nothing is wrong. I simply did not want my macro do be dependent on such options. -- Peter Hunkeler
Re: How to separate instructions and data generated in macro?
On 2017-01-14, at 18:22, Tony Thigpen wrote: > > I think I was not clear enough. Yes, I use an extended R13 area for program > work areas, but that is not what the original post was discussing. It was > discussing a generic user written macro that currently required inline an > inline data area. And writing a replacement that did not use an inline data > area. > I understand. Some decades agp I watched a co-worker make some mathematical function routines reentrant by saving and restoring only some of the registers and using the caller's RSA of the unused registers as WSA. This could wreak havoc with dump analysis. I don't recall if he mitigated by storing the unmodified registers in the RSA immediately before return. I believe he never obtained/ freed his own RSA. One driving concern was that the 370 hardware required working storage to do fixed<->floating conversion. -- gil
Re: How to separate instructions and data generated in macro?
Gil, I think I was not clear enough. Yes, I use an extended R13 area for program work areas, but that is not what the original post was discussing. It was discussing a generic user written macro that currently required inline an inline data area. And writing a replacement that did not use an inline data area. To cleanly use a new version of such macros anywhere the current one is used, it needs to be a drop-in macro that does not need other changes to the source. And in actuality, any common utility macro is move useful if there is no need for the programmer to add any additional work areas to the program. In those cases, the save area can be a good choice. Personally, 95% of my code uses entry and exit macros that define several standard LOCTR areas. And most of my macros utilize these LOCTRs as ways to define storage. But there are still those small test programs that don't use my standard entry and exits, so I keep a few macros that can be dropped into a program (mostly for debugging) that don't require anything other than the standard R13 save area. Tony Thigpen Paul Gilmartin wrote on 01/14/2017 11:58 AM: On 2017-01-13, at 14:00, Tony Thigpen wrote: Although I used LOCTR extensively in my programs, I also use the save area (r13) as a work area for small home-grown macros. (As long as the code in the macro does not call something that saves/restores in the save area.) Extend the save area. Some have criticized even that practice. I don't understand why. Some prejudice that R13 should not be used as a work area base? -- gil
Re: How to separate instructions and data generated in macro?
Absolutely. That is standard for LE non-XPLINK linkage. You tell LE at the entry point how much "extra" R13 storage you need. (I of course do it with a calculated EQU.) Gives you stack-type storage for assembler just like in C and so forth. Would make it easy, for example, to write an assembler routine that was potentially recursive. Back when registers were more precious I thought I had died and gone to heaven when I figured out that R13 could be used to satisfy two purposes. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, January 14, 2017 8:59 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: How to separate instructions and data generated in macro? On 2017-01-13, at 14:00, Tony Thigpen wrote: > Although I used LOCTR extensively in my programs, I also use the save > area (r13) as a work area for small home-grown macros. (As long as the > code in the macro does not call something that saves/restores in the > save area.) > Extend the save area. Some have criticized even that practice. I don't understand why. Some prejudice that R13 should not be used as a work area base?
Re: How to separate instructions and data generated in macro?
On 2017-01-13, at 14:00, Tony Thigpen wrote: > Although I used LOCTR extensively in my programs, I also use the save area > (r13) as a work area for small home-grown macros. (As long as the code in the > macro does not call something that saves/restores in the save area.) > Extend the save area. Some have criticized even that practice. I don't understand why. Some prejudice that R13 should not be used as a work area base? -- gil
Re: How to separate instructions and data generated in macro?
Although I used LOCTR extensively in my programs, I also use the save area (r13) as a work area for small home-grown macros. (As long as the code in the macro does not call something that saves/restores in the save area.) Tony Thigpen Peter Hunkeler wrote on 01/13/2017 11:27 AM: I have an old macro I wrote in the late 80ies that generates code to invoke WTO with variable text. Initially, the macro did not generate reentrant code. Then I changed that quite a while ago, but did not care to separate the instructions from the data it generates. The code merely jumped around the static data. Although that code is never used in perfomance critical environments, I now want to separate instructions and data, just for the fun of it,to avoid cache trashing. First thought was to generate a separate, named CSECT (or RSECT) to assemble the data statements. Then I recognized that there would be a conflict if multiple sources were using the macro, and the objects would be linked together. Allowing the user to choose the CSECT name is only half an option. What if he does not now that another object was also using the macro and by chance the same CSECT name was used? CSECT names longer than 8 would force the use of GOFF (If I understand correctly), which I do not want to force. So building a longer name, most probably unique name does not work either. I never used unnamed CSECTs, but am thinking, this could be an option. Unnamed CSECTs cannot be resumed, so each invocation of the macro would generate a new unnamed section. A load address instruction with an =A(dataxyz), where dataxyz is a unique name in the unnamed section, would make the data addressable to the code. Would this work? Can there be a problem linking mulitple objects, each unsing the macro, into one load module? Any other problem? Any other solution? -- Peter Hunkeler
Re: How to separate instructions and data generated in macro?
>> LOCTR is your friend. and a very good I like to add. John - give up the base for the code (only for data and constants) - use whatever method you like to convert to relatives only (MAKEREL, IEABRC/X, DIY) and you are almost there. Martin
Re: How to separate instructions and data generated in macro?
On 1/13/2017 8:27 AM, Peter Hunkeler wrote: I have an old macro I wrote in the late 80ies that generates code to invoke WTO with variable text. Initially, the macro did not generate reentrant code. Then I changed that quite a while ago, but did not care to separate the instructions from the data it generates. The code merely jumped around the static data. Although that code is never used in perfomance critical environments, I now want to separate instructions and data, just for the fun of it,to avoid cache trashing. LOCTR is your friend. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/
Re: How to separate instructions and data generated in macro?
And of course the traditional solution to this problem is MF=E/MF=L variants of the macro. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Charles Mills Sent: Friday, January 13, 2017 9:18 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: How to separate instructions and data generated in macro? Depending on how complex the generated data is it might be possible to generate it as a literal. The location of literal data is always somewhat separate from machine instructions and easy to control with LTORG and LOCTR. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Peter Hunkeler Sent: Friday, January 13, 2017 8:27 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: How to separate instructions and data generated in macro? I have an old macro I wrote in the late 80ies that generates code to invoke WTO with variable text. Initially, the macro did not generate reentrant code. Then I changed that quite a while ago, but did not care to separate the instructions from the data it generates. The code merely jumped around the static data. Although that code is never used in perfomance critical environments, I now want to separate instructions and data, just for the fun of it,to avoid cache trashing.
Re: How to separate instructions and data generated in macro?
Depending on how complex the generated data is it might be possible to generate it as a literal. The location of literal data is always somewhat separate from machine instructions and easy to control with LTORG and LOCTR. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Peter Hunkeler Sent: Friday, January 13, 2017 8:27 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: How to separate instructions and data generated in macro? I have an old macro I wrote in the late 80ies that generates code to invoke WTO with variable text. Initially, the macro did not generate reentrant code. Then I changed that quite a while ago, but did not care to separate the instructions from the data it generates. The code merely jumped around the static data. Although that code is never used in perfomance critical environments, I now want to separate instructions and data, just for the fun of it,to avoid cache trashing. First thought was to generate a separate, named CSECT (or RSECT) to assemble the data statements. Then I recognized that there would be a conflict if multiple sources were using the macro, and the objects would be linked together. Allowing the user to choose the CSECT name is only half an option. What if he does not now that another object was also using the macro and by chance the same CSECT name was used? CSECT names longer than 8 would force the use of GOFF (If I understand correctly), which I do not want to force. So building a longer name, most probably unique name does not work either. I never used unnamed CSECTs, but am thinking, this could be an option. Unnamed CSECTs cannot be resumed, so each invocation of the macro would generate a new unnamed section. A load address instruction with an =A(dataxyz), where dataxyz is a unique name in the unnamed section, would make the data addressable to the code. Would this work? Can there be a problem linking mulitple objects, each unsing the macro, into one load module? Any other problem? Any other solution? -- Peter Hunkeler
Re: How to separate instructions and data generated in macro?
On 2017-01-13, at 09:27, Peter Hunkeler wrote: > > Although that code is never used in perfomance critical environments, I now > want to separate instructions and data, just for the fun of it,to avoid cache > trashing. > I'll second John's suggestion of LOCTR. Same CSECT, but remote. You may want to prefix your program with empty LOCTRs to control the order of object code. This was discussed in these lists long ago with one contributor's objection that such LOCTRs compromised modularity of the source. > First thought was to generate a separate, named CSECT (or RSECT) to assemble > the data statements. Then I recognized that there would be a conflict if > multiple sources were using the macro, ... > > Unnamed CSECTs cannot be resumed, so each invocation of the macro would > generate a new unnamed section. A load address instruction with an > =A(dataxyz), where dataxyz is a unique name in the unnamed section, would > make the data addressable to the code. > > Would this work? Can there be a problem linking mulitple objects, each unsing > the macro, into one load module? Any other problem? > Unnamed CSECTs are anathema to SMP/E service since they can't be replaced and accumulate secularly with successive module updates. If you accept GOFF, of course each data CSECT can be named as the parent CSECT with a distinctive suffix. E.g.: CODESECT.WtoText. SMP/E is hostile to long names as ++MOD element names but friendly to them in the CSECT() option. What's wrong with GOFF? -- gil
Re: How to separate instructions and data generated in macro?
On Fri, Jan 13, 2017 at 10:27 AM, Peter Hunkeler wrote: > I have an old macro I wrote in the late 80ies that generates code to > invoke WTO with variable text. Initially, the macro did not generate > reentrant code. Then I changed that quite a while ago, but did not care to > separate the instructions from the data it generates. The code merely > jumped around the static data. > > Although that code is never used in perfomance critical environments, I > now want to separate instructions and data, just for the fun of it,to avoid > cache trashing. > > First thought was to generate a separate, named CSECT (or RSECT) to > assemble the data statements. Then I recognized that there would be a > conflict if multiple sources were using the macro, and the objects would be > linked together. Allowing the user to choose the CSECT name is only half > an option. What if he does not now that another object was also using the > macro and by chance the same CSECT name was used? > > CSECT names longer than 8 would force the use of GOFF (If I understand > correctly), which I do not want to force. So building a longer name, most > probably unique name does not work either. > > I never used unnamed CSECTs, but am thinking, this could be an option. > > Unnamed CSECTs cannot be resumed, so each invocation of the macro would > generate a new unnamed section. A load address instruction with an > =A(dataxyz), where dataxyz is a unique name in the unnamed section, would > make the data addressable to the code. > > Would this work? Can there be a problem linking mulitple objects, each > unsing the macro, into one load module? Any other problem? > > Any other solution? > I've used the LOCTR instruction to have "interleved" data and instructions which reside in the same CSECT. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.asma400/loctr.htm PROGRAM CSECT CODE LOCTR DATA LOCTR CODE LOCTR SAVE (14,12) LR R11,R15 USING *,R11 LA R1,SAVEAREA DATA LOCTR SAVEAREA DC 18A(0) ST R13,4(,R1) ST R1,8(,R13) LR R13,R1 LR1,4(,R13) LR1,24(,R1) RESTORE ORIGINAL R1 CODE LOCTR ... RETURN DS 0H CODE LOCTR L R13,4(,R13) RETURN (14,12),T,RC=0 DATA LOCTR LTORG ... OTHER DATA END PROGRAM > > > > > > -- > Peter Hunkeler > -- There’s no obfuscated Perl contest because it’s pointless. —Jeff Polk Maranatha! <>< John McKown
