Re: VAX: Another small GAS bug?

On 7/4/24 21:09, Maciej W. Rozycki wrote:
>   I can't say offhand what the VAX assembly language semantics is here, but
> I find the use of uninitialised data for an instruction operand clearly a
> bug in GAS (and then a rather nasty one).
>
>   I think the tool is supposed to either reject an immediate F-floating
> operand given to an instruction that operates on D-floating data or make
> an arithmetic conversion of the operand to correctly represent it in the
> D-floating format.  Likewise for other data format mismatches.
>
>   What actually to do I'd expect to see in the VAX assembly language
> reference specification.  If not fixed right away, this needs to be filed
> as a bug upstream, so that we don't forget about it.

 From reading the VAX MACRO reference, and after spending an hour or two 
setting up VMS in SIMH and playing with it, it looks as if VAX MACRO 
will determine the format used to encode a floating point operand from 
the instruction (or the pseudo op e.g. .F_FLOATING, .G_FLOATING).  
Floating point literals are specified in a neutral form (section 3.2.2 
in the VAX MACRO reference, basically the snn.nnEsnn format we're used 
to seeing) - so this implementation problem, where the floating point 
format used for an operand doesn't match the instruction's requirements, 
doesn't happen.

GAS for VAX clearly doesn't do this, instead requiring the programmer to 
specify the format to use for the operand.  I'm sure that there is a 
Very Good Reason why this is so.

I've worked out where to clear the buffer holding the parsed floating 
point operand, and this fixes the case where a F-floating immediate 
operand is specified where an instruction expects a D-floating operand 
(since these have the same number of sign and exponent bits in the same 
locations in the first longword), but the real problem, that the format 
of the operand doesn't match that expected by the instruction, remains.  
I think that there's enough information available to detect this and 
report an error, at least where the formats have different sizes.

I've also noticed that GAS will happily assemble code like this

            .type   f4, @function
    f4:    .word    0
         movd    $0g0.25, %r0
         ret

producing

    0000009b <f4>:
       9b:    00 00           .word 0x0000 # Entry mask: < >
       9d:    70 8f f0 3f     movd $0x0000000000003ff0 [d-float],r0
       a1:    00 00 00 00
       a5:    00 00 50
       a8:    04              ret

i.e. the bit pattern representing 0.25 is correct for a G-float operand 
but not so for a D-float.

The GAS documentation doesn't seem to specify what should happen in this 
case.  Programmer beware, I suppose!

cheers

kalvis