On 2010-12-20 15:24, Edward Jaffe wrote:
On 12/20/2010 1:13 PM, Robert A. Rosenberg wrote:
At 11:03 -0500 on 12/20/2010, David Bond wrote about Re: Baseless vs
Based:
A good use for LARL is to set up the base register for the constants
- and
maybe the modifiable data area if the program is not reentrant.
LARL can
even be used to get the address of other control sections. But I
think you
are trying to use LARL for everything.
A LARL reference to another control section is playing with fire
since the displacement of the CSECT being referenced can change at
Bind Time. Only a ACON can track the real location/displacement:
Since z/OS 1.7 (and even better in 1.8) the binder manages relative
references
to external symbols as needed.
Always presuming that the size of your load module does not
exceed the relative displacement reach. Or remembering
that SMP/E may rearrange CSECTs at its whim.
I'm pleasantly surprised: this implies considerable collusion
between HLASM and Binder to generate and resolve complex
relocatable constants, divided by 2, and with the bits
discontiguous. I'd not have dared to suggest such a
facility as a Requirement. That two(?) development groups
expended such effort effort shows that IBM, at least
perceives considerable value in relative addressing.
Perhaps it's in support of that compiler that I hear
rumors about.
On 2010-12-20 15:26, John Ehrman wrote:
> John Bodoh observed:
>
>> I guess what irks me is that the macro has no way of knowing what to
>> generate. ...
>
> If you're willing to do a little extra work, you might be able to
assign a
> Program Attribute to the symbols your macros must reference (either with
> the DC or EQU instructions) that indicates where the symbol is defined,
> what program-relevant properties it has, and therefore what kind(s) of
> instruction(s) might be needed to address it.
>
I suspect the OP is willing to expend that extra work, but
loath to require it of his clients.
-- gil
