Bug 13937 - Incorrect opcode generated for FDIVRP
Summary: Incorrect opcode generated for FDIVRP
Status: RESOLVED INVALID
Alias: None
Product: binutils
Classification: Unclassified
Component: gas (show other bugs)
Version: 2.22
: P2 critical
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-02 17:32 UTC by Zbigniew Jurkiewicz
Modified: 2012-04-04 12:36 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zbigniew Jurkiewicz 2012-04-02 17:32:29 UTC
When gas generates opcode for instruction FDIVRP (without arguments)
in 32-bit mode, it incorrectly puts DEF9 instead of DEF1.

This also happens in older versions of gas.
Comment 2 Zbigniew Jurkiewicz 2012-04-03 06:23:58 UTC
(In reply to comment #1)
> See http://sourceware.org/binutils/docs-2.22/as/i386_002dMnemonics.html .

The documentation says:

Several x87 instructions, `fadd', `fdiv', `fdivp', `fdivr', `fdivrp', `fmul', `fsub', `fsubp', `fsubr' and `fsubrp', are implemented in AT&T System V/386 assembler with different mnemonics from those in Intel IA32 specification.

In the case of fdivrp it is not true.  The mnemonic IS ACCEPTED, but the 
generated opcodes for fdivrp and fdivp (when called without arguments)
are swapped.  No other assembler does this.
Comment 3 Alan Modra 2012-04-03 08:14:57 UTC
The documentation is poor, but you're quite wrong in your claim that "No other assembler does this."  gas generates the opcodes it does precisely for compatibility with an old sysv assembler.  You can't change gas without also changing gcc.
Comment 4 Zbigniew Jurkiewicz 2012-04-03 10:07:32 UTC
Dnia 2012-04-03, wto o godzinie 08:14 +0000, amodra at gmail dot com
pisze:

> --- Comment #3 from Alan Modra <amodra at gmail dot com> 2012-04-03 08:14:57 UTC ---
> The documentation is poor, but you're quite wrong in your claim that "No other
> assembler does this."  gas generates the opcodes it does precisely for
> compatibility with an old sysv assembler.

You mean AT&T sysv.  SCO Unix V used Microsoft C compiler and
assembler.  

>   You can't change gas without also
> changing gcc.
> 

Right, and for C programming it does not matter.

But you can change and clarify the documentation to say that 
FDIV opcodes are not ,,changed'', but have their meaning swapped as
compared to Intel and AMD documentation.  as does not describe
machine instruction, so students of assembly programming must use Intel
or AMD manuals - the only source for catalogue of instructions.

ZJ
Comment 5 Ian Lance Taylor 2012-04-03 12:36:53 UTC
Or use the .intel_mnemonic pseudo-op or the -mmnemonic=intel option.

As far as I can see the documentation is correct.  The instructions are implemented with different mnemonics.  The mnemonic for the Intel fdivrp instruction happens to be fdivp in AT&T mode, and the mnemonic for the Intel fdivp instruction happens to be fdivrp in AT&T mode.
Comment 6 Zbigniew Jurkiewicz 2012-04-04 06:06:09 UTC
Dnia 2012-04-03, wto o godzinie 12:36 +0000, ian at airs dot com pisze:
> http://sourceware.org/bugzilla/show_bug.cgi?id=13937
> 
> --- Comment #5 from Ian Lance Taylor <ian at airs dot com> 2012-04-03 12:36:53 UTC ---
> Or use the .intel_mnemonic pseudo-op or the -mmnemonic=intel option.
> 
> As far as I can see the documentation is correct.  The instructions are
> implemented with different mnemonics.

"The mnemonic for the Intel fdivrp
instruction happens to be fdivp in AT&T mode, and the mnemonic for the Intel
fdivp instruction happens to be fdivrp in AT&T mode."

And this is the information I would expected to find in documentation,
otherwise the only way to find it is to look at code dump and
check instruction codes - not very pedagogic to suggest to students.

ZJ
Comment 7 Ian Lance Taylor 2012-04-04 12:36:45 UTC
Well, the gas manual is not intended to serve as a documentation for the machine instructions.  It could be written that way, but it is not, and it would be a fair amount of work to get it to that point.  The idea is that you also have a manual for the AT&T syntax and mnemonics, such as was distributed with System V.

Since nobody actually has those manuals any more, I would recommend using .intel_syntax when hand writing assembler code.  The assembler default is chosen based on the gcc default.