Gnu assembler fsub "bug" status

Gnu assembler fsub "bug" status

[Michael Guyver]

Hi there,

I happened across the gas bug in which it produces the wrong opcodes
for the non-commutative FP arithmetic instructions where %st(0) is the
source register. While looking into the problem and how to avoid it, I
blogged about what I found (at
http://www.mindfruit.co.uk/2012/03/trouble-with-fsub.html). I was
wondering about the current state of play regarding the issue?

It seems to me that there are three options for hand-assembly writers
to deal with this, either by compiling binutils with
CPPFLAGS=-DSYSV386_COMPAT (useful if you want correct instructions in
AT&T syntax in objdump), assembling with 'as' using -mmnemonic=intel
or specifying the directive .intel_mnemonic in the source. However,
it's really not clear (to me, at least) from the docs or Honiju Lu's
patches what the effects of using the last two options are, since it
appears to switch on intel syntax if you specify intel mnemonic; and
further, those flags are set equal to !SYSV386_COMPAT as well.

I was wondering if you could elaborate on what that means for my
assembly code? If I specify .intel_mnemonic (and therefore get
.intel_syntax), have all my operands changed place? If this is
well-trodden ground, perhaps you could point me to some documentation
which would clear things up for me, please? Is it possible to have
AT&T syntax yet have "fixed" FP opcodes?

Regards

Michael

Re: Gnu assembler fsub "bug" status

[Michael Guyver]

Apologies, it seems the correct mailing list for this question is
binutils@sourceware.org. Of course, feel free to comment.

Michael

On 16 March 2012 11:19, Michael Guyver <michael.guyver@gmail.com> wrote:
> Hi there,
>
> I happened across the gas bug in which it produces the wrong opcodes
> for the non-commutative FP arithmetic instructions where %st(0) is the
> source register. While looking into the problem and how to avoid it, I
> blogged about what I found (at
> http://www.mindfruit.co.uk/2012/03/trouble-with-fsub.html). I was
> wondering about the current state of play regarding the issue?
>
> It seems to me that there are three options for hand-assembly writers
> to deal with this, either by compiling binutils with
> CPPFLAGS=-DSYSV386_COMPAT (useful if you want correct instructions in
> AT&T syntax in objdump), assembling with 'as' using -mmnemonic=intel
> or specifying the directive .intel_mnemonic in the source. However,
> it's really not clear (to me, at least) from the docs or Honiju Lu's
> patches what the effects of using the last two options are, since it
> appears to switch on intel syntax if you specify intel mnemonic; and
> further, those flags are set equal to !SYSV386_COMPAT as well.
>
> I was wondering if you could elaborate on what that means for my
> assembly code? If I specify .intel_mnemonic (and therefore get
> .intel_syntax), have all my operands changed place? If this is
> well-trodden ground, perhaps you could point me to some documentation
> which would clear things up for me, please? Is it possible to have
> AT&T syntax yet have "fixed" FP opcodes?
>
> Regards
>
> Michael