Re: GAS problems

[Alan Modra <alan at SPRI dot Levels dot UniSA dot Edu dot Au>]

On Mon, 18 Oct 1999, Horst von Brand wrote:

> Alan Modra <alan@SPRI.Levels.UniSA.Edu.Au> said:
> > On Sun, 17 Oct 1999, Horst von Brand wrote:
> > > The lcc C compiler on ia32 generates "fxxxp %st(1),%st" instructions to
> > > handle floating point operations. This is handled wrong by H.J.Lu's
> > > binutils-2.9.5.0.16. Note that now it translates "fsubp %st(1),%st" into
> > > "fsubp %st,%st(1)", which does something very different. Also, the
> > > instructions are legal AFAIK (they used to work before), so either no
> > > warning is needed or you could use f.ex. "fsubrp %st,%st(1)" if there is a
> > > penalty of some sort. In any case, I would prefer you left them alone.
> 
> > These floating point operations are a real pain, but in this case lcc is
> > doing something wrong.  There is no such x86 instruction.  What should
> > "fsubp %st(1),%st" do?  I'd imagine it should do st <- st - st(1), then
> > pop off the result, which is a bit silly.
> 
> No, it would do st(0) - st(1), pop both and push the result. Note that this
> is _not_ st(1) - st(0).

Well, your imagination is better than mine :-)  Regardless of what we
think the instruction should do, there is no such x86 instruction.  Check
the intel manuals.

> >                                           Note that older binutils
> > silently did the same translation we now do (and older gcc emitted this
> > wrong instruction too)
> 
> They did not: lcc used to work.

Can I have a testcase, with lcc's generated asm file?

> > FYI, here's a comment I added to binutils/include/opcode/i386.h, just to
> > make you aware of a horrible kludge.
> > 
> > /* 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 is _not_ expected behaviour! It gets the operation backwards. If you
> do that, use fsubr in the "translation".

Are you saying that `fsub %st,%st(3)' should result in st(3) <- st-st(3) ?
That's different to every other subtract instruction.  Consider
subl `%eax,%ebx' and `subl %ebx,%eax'.  In general `op l,r' => r <- r op l
at least in AT&T syntax.

Ian Taylor and I checked gas behaviour vs Unixware fairly exhaustively
back in Jun 1998, when this was all tidied up.

> >    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).  Look for FloatDR below.  */
> > 
> > #ifndef UNIXWARE_COMPAT
> > /* Set non-zero for broken, compatible instructions.  Set to zero for
> >    non-broken opcodes at your peril.  gcc generates UnixWare
> >    compatible instructions.  */
> > #define UNIXWARE_COMPAT 1
> > #endif
> > 
> > I would love to get rid of this stupidity, but that needs a
> > synchronised update of both gcc and binutils.
> 
> Strange. gcc and lcc used to work for me. Any specific testcase that shows
> gcc generating garbage?

Attached.  Use a fairly old gcc (2.7.2 ?) to show the problem.
/*
 * inspired by glibc-2.0.6/sysdeps/libm-ieee754/s_nextafterf.c
 *
 * gcc -O2 -S -DOP=+ gives faddp %st(1),%st
 * gcc -O2 -S -DOP=* gives fmulp %st(1),%st
 * gcc -O2 -S -DOP=- gives fsubrp %st(1),%st
 * gcc -O2 -S -DOP=/ gives fdivrp %st(1),%st
 */

#ifndef OP
#define OP *
#endif

typedef int int32_t __attribute__ ((__mode__ (  __SI__ ))) ;
typedef unsigned int u_int32_t __attribute__ ((__mode__ (  __SI__ ))) ;

typedef union
{
  float value;
  u_int32_t word;
} ieee_float_shape_type;

float __nextafterf(float x, float y)
{
 int32_t hx,hy,ix,iy;

 {
  ieee_float_shape_type gf_u;
  gf_u.value = x;
  hx = gf_u.word;
 }
 {
  ieee_float_shape_type gf_u;
  gf_u.value = y;
  hy = gf_u.word;
 }
 ix = hx&0x7fffffff;
 iy = hy&0x7fffffff;

 if ( ix > 0x7f800000 || iy > 0x7f800000 )
    return x+y;
 if (x == y) return x;
 if (ix == 0)
   {
    {
     ieee_float_shape_type sf_u;
     sf_u.word = (hy&0x80000000) | 1;
     x = sf_u.value;
    }
    y = x*x;
    if (y == x) return y; else return x;
   }
 if (hx >= 0)
   {
    if (hx > hy)
       hx -= 1;
    else
       hx += 1;
   }
 else
   {
    if (hy >= 0 || hx > hy)
       hx -= 1;
    else
       hx += 1;
   }
 hy = hx & 0x7f800000;
 if (hy >= 0x7f800000)
    return x+x;
 if (hy < 0x00800000)
   {
    y = x OP x;
    if (y != x)
      {
       ieee_float_shape_type sf_u;
       sf_u.word = hx;
       y = sf_u.value;
       return y;
      }
   }
 {
  ieee_float_shape_type sf_u;
  sf_u.word = hx;
  x = sf_u.value;
 }
 return x;
}