On Fri, Jan 13, 2017 at 10:27 AM, Peter Hunkeler <p...@gmx.ch> 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.
SAVEAREA DC 18A(0)
L R1,24(,R1) RESTORE ORIGINAL R1
RETURN DS 0H
... OTHER DATA
> Peter Hunkeler
There’s no obfuscated Perl contest because it’s pointless.