Subject: Re: shocking speed performance!
To: None <kim@pvv.ntnu.no>
From: Richard Earnshaw <rearnsha@arm.com>
List: port-arm32
Date: 05/21/1999 10:45:13
> > > Oooohhhh, I don't know about that.  The NetBSD/vax port uses native VAX
> > > floating point operations, and they're not IEEE compliant.  They're VAX
> > > D_float format.   There's the odd problem here and there, but it doesn't
> > > wreak great havoc.
> > 
> > But it's always been that way on the Vax (IIRC Vax FP predates IEEE).  On 
> > the ARM, it has always been IEEE, so to change would break compatibility.
> 
> It would ONLY break float compatibility. Floats are mostly used just
> inside programs, not for communication with other programs. Usually
> reals are stored as ASCII numbers in text files, not as IEEE numbers.
> 
> Besides, as i suggested only changing the format of floats, not doubles,
> IEEE format would also be available. In C numbers are by default passed
> as doubles anyway.

Not for ANSI in the presence of a prototype that declares the parameter as 
float.

> The whole point of the endeavour was to have the
> possibility of accelerating math about tenfold for simple operations
> of lesser accuracy when needed, such as in 3d programming, numerical
> simulations, etc. 
> 
> Kim0


And as I said, any program that had 

  float f;

   ...

  if ( f < (float)0.5 )
    ...


would now fail if it were compiled before your change because the binary 
representation is now different.

The (trivial) program below illustrates this.

int x (float a)
{
  float b = a * (float)3.0;

  if (b < (float)0.5)
    return 1;
  return 0;
}

Which compiles to:

_x:
        mov     ip, sp
        stmfd   sp!, {fp, ip, lr, pc}
        ldr     r1, L5  @ float
        sub     fp, ip, #4
        bl      ___mulsf3
        ldr     r1, L5+4        @ float
        bl      ___ltsf2
        mov     r0, r0, lsr #31
        ldmea   fp, {fp, sp, pc}
L6:
        .align  0
L5:
        .word 0x40400000        @ float 3.00000000000000000000e0
        .word 0x3f000000        @ float 5.00000000000000000000e-1

This is *user* code and calls *library* functions.  If the two differ over 
the format then the results will be garbage.

Note:  The current soft-float code for the NetBSD/arm32 is written in C.  
It generally gets the right answers, but it's not especially efficient.  
It would be really useful if someone could at least code the common cases 
in assembler (maybe punting to C code to handle the corner cases such as 
NaNs and infinity).