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, @functionproducing
f4: .word 0
movd $0g0.25, %r0
ret
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