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

Reply via email to