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
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?