IMHO, if you are a macro provider and have no control on the environment
provided by the open code (which comes from the customer's programmer),
the literal approach is more dangerous, because it assumes that the
programmer
will provide space and addressibility for the literals.
Doing LTORG yourself cannot work, as you mentioned already, because you
risk
to activate literals collected by the client's open code. This will lead
to problems, IMO.
This said, I would try to avoid constant definitions in such macros, if
possible.
Use instructions with immediate operands instead.
If you absolutely need constants, then in a baseless environment you
must IMO
establish a temporary base register, for example using register 1, 14 or
15,
which you maybe change anyway during your macro expansion.
The answers of some other posters which relate to general program layout
don't
really help in this situation, because you cannot control this when you
simply
provide a (third party) macro used by the customer's application
programmers.
HTH, kind regards
Bernd
Am 08.11.2021 um 01:25 schrieb Tony Thigpen:
I finally am to the point where I no longer need to worry about
specific customers having hardware that does not support relative
instructions, so I am updating some macros I provide to be baseless.
What is the 'preferred' approach to macro generated constants? In the
past, I have used both inline constants that I branch around, and
ltorg literals (=c'x').
In the past, I have been bitten by using ltorg literals and the client
did not put a LTORG after my macro causing a 'no active base register'
issue. So, I am thinking inline with a BRAS is better.
Maybe there is another approach that I missed?
Suggestions?
Tony Thigpen
