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
