Re: x86 fp fix

[Alan Modra <alan at linuxcare dot com dot au>]

On Sat, 25 Mar 2000, Robert Lipe wrote:

> > Intel mode fp assembly output was wrong, mainly due to a wrong
> > assumption about how the Unixware assembler is broken.  Ian Taylor
> > and I, with help from Robert Lipe, thrashed out exactly how the
> > Unixware assembler was broken quite a while ago (so that gas would be
> 
> I'm afraid I don't recall this conversation and I can't find it in any
> of my mail folders.  (This isn't to say it didn't happen. :-)

I can't find it now either.  Maybe it was someone else.  In any case, I
meant it as an honourable mention, rather than trying to spread the blame
:-)

> 
> Can you please offer a testcase or a pointer to the mail thread so we
> can determine exactly which of the UnixWare assemblers are "broken"?
> Since UW has a history of some 8 or more years (and the AT&T assembler
> that it came from probably another 5 or 6), it's helpful to figure out
> exactly which ones would be affected.  

All, I believe.
Here's a comment I wrote in binutils/include/opcodes/i386.h

/* The UnixWare assembler, and probably other AT&T derived ix86 Unix
   assemblers, generate floating point instructions with reversed
   source and destination registers in certain cases.  Unfortunately,
   gcc and possibly many other programs use this reversed syntax, so
   we're stuck with it.

   eg. `fsub %st(3),%st' results in st = st - st(3) as expected, but
   `fsub %st,%st(3)' results in st(3) = st - st(3), rather than
   the expected st(3) = st(3) - st

   This happens with all the non-commutative arithmetic floating point
   operations with two register operands, where the source register is
   %st, and destination register is %st(i).  See FloatDR below.

   The affected opcode map is dceX, dcfX, deeX, defX.  */

> For example, if it's "SVR4/386" or "Unixware 1.x" that's affected, I
> won't even pretend to care and would rather just delete this whole mess.

I'd like to delete it too, but that's rather impractical as it would make
a new gcc incompatible with an old gas, and a new gas incompatible with
old gcc, let alone the problem of validating existing fp assembler code.

> 
> Also, I'm FP impaired, so don't expect me to deduce much in this area.

Here are examples of `broken' opcodes.  You might like to verify that your
Unixware assemblers produce the same.
   1 0000 DCE3           fsub %st,%st(3)
   2 0002 DCEB           fsubr %st,%st(3)
   3 0004 DCF3           fdiv %st,%st(3)
   4 0006 DCFB           fdivr %st,%st(3)
   5 0008 DEE3           fsubp %st,%st(3)
   6 000a DEEB           fsubrp %st,%st(3)
   7 000c DEF3           fdivp %st,%st(3)
   8 000e DEFB           fdivrp %st,%st(3)