On 2014-11-06, at 04:24, Jonathan Scott wrote:
>
> 1. Dependent USING support for long displacements
>
> For 20-bit displacement support, a dependent USING should be
> able to be defined anywhere within the 20-bit addressable
> range of an existing base register. (This was also discussed
> on the mailing list some time ago).
>
I would not impose the 20-bit limit. HLASM should immunize itself
against potential hardware extensions. And consider:
D-Loc Object Code Addr1 Addr2 Stmt Source Statement
000000 00000 00000 1 X DSECT
000000 00000 00004 2 C CSECT
R:C 00000 3 USING C,R12
C 000 653601 00000 4 USING X-999999999,C
000000 4110 C001 653602 5 LA R1,X-999999998
6 *
7 * But:
8 USING X,C+999999999
** ASMA307E No active USING for operand C+999999999
** ASMA435I Record 8 in user.DEPUSING.JOB06303.D0000101.? on volume:
Line 4 results in no messages, and the resolution at line 5
is algebraically correct. The programmer's objective is
mysterious, but there's no reason to prohibit the behavior.
The USING at line 8 is algebraically equivalent to that at
line 4, but it it produces an error message. Why? I'd
urge that there be no limit on the range at the definition
of a USING other than that imposed by the 32-bit signed
integer arithmetic uniformly used by HLASM.
Discipline might require stronger overflow checking during
base-displacement resolution. I can today demonstrate a
case where HLASM generates an algebraically incorrect
resolution, apparently because it ignores an overflow that
occurs during the calculation.
> 2. USING support for long displacement limits
>
> USING needs additional support for lower and upper limits for
> 20-bit displacements.
>
> The suggested solution is to extend the first parameter of
> the USING statement to the following form with two new
> optional subparameters:
>
> USING (base,limit,lower,upper),...
> ...
> The above change for USING limits also allows the same base
> registers to be used to address multiple discontiguous parts
> of the same section, ...
>
I question the value of this. It leads to the paradoxical
situation that a certain address may be addressable with
short displacement but not with long.
I suspect that the design motivation is largely to avoid
a syntactic anomaly introduct by alternatives such as:
USING (base,upper) (Current syntax)
But either extension:
USING (base,upper,lower) ("upper" appears before "lower")
or:
USING (base,lower,upper) ("upper" is 3rd positional parameter rather
than second.)
> 3. DROP by address
> ...
> The suggested solution is that if an operand to DROP is a
> relocatable expression rather than a register, it drops the
> USING statement that would be used to resolve the relevant
> address.
>
Are dependent USINGs referring to the same base register
allowed to overlap? There should be no objection to this
provided that they resolve to identical base and displacement
regardless which USING is used. But this introduces an
ambiguity in "DROP by address" when that address can be
resolved, albeit equivalently, by either of two dependent
USINGs.
-- gil
