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).