On 09/09/10 12:13, Thomas David Rivers wrote:
>
> And, to add to the list, here's what DASM generates:
>
> DASM V1.85.05 2010/09/09 13:54
> 00000000 00000000 00000008 1 NEGDISP CSECT
> 2 USING -4096,R1
> ** DASM305E Operand 1 does not refer to location within reference control
> section
> ** DASM435I Record 2 in negdisp.asm
>
I'm just a little uncomfortable with mention of a "reference
control section" when the base address is an absolute expression.
Or is there a putative absolute "control section"? At times I've
wished there were, so I could code:
ANSWER EQU 42
ENTRY ANSWER
(There are recognized reasons for creating an ESD LD entry
other than being able to branch to it.)
> 00000000 0000 0000 00000000 3 LA R3,-4(R2)
> ** DASM028E Invalid displacement
> ** DASM435I Record 3 in negdisp.asm
> 00000004 0000 0000 00000000 4 LA R3,-4(,R2)
> ** DASM028E Invalid displacement
> ** DASM435I Record 4 in negdisp.asm
>
>
> I wonder why HLASM allows the negative displacement?
> The HLASM documentation (HLASM V1R6 Language Reference manual)
> for an "Ordinary USING" indicates:
>
> base
> specifies a base address, which can be a relocatable
> or an absolute expression. The value of the expression
> must lie between 0 and 2**31-1.
>
> and -4096 doesn't lie in that range...
>
And this is a little fuzzy. Is comparison of a relocatable
expression to an absolute constant (0 or 2**31-1) well
defined? (Or do those bounds apply only when the base is
absolute?)
> Furthermore, this same document describes the valid
> values used for displacements in an "Explicit Address"
> (see page 85), where it says:
>
> Explicit address:
>
> An explicit address is specified by coding two absolute
> expressions as follows:
>
> * The first is an absolute expression for the
> displacement, whose value must lie in the range 0
> through 4095 (4095 is the maximum value that can be
> represented by the 12 binary bits available for the
> displacement in the object code), or in the range
> -524,288 to 524,287 for long-displacement
> instructions.
>
> ...
>
> and, -4 is not in the range 0 through 4095.
> Even if you assume the assembler is simply
> wrapping-around and treating -4 as X'FFFFFFFC',
> X'FFFFFFFC' is not in the range 0 through 4095
> either.
>
Here I agree. And no one in this thread has contested
this point.
-- gil
