Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)

[Konstantinos Margaritis <markos@genesi-usa.com>]

On Thursday 15 July 2010 18:20:07 Konstantinos Margaritis wrote:
> On Thursday 15 July 2010 17:34:01 Martin Guy wrote:
> > I still doubt that the disruption and extra work for the community of
> > Debian package maintainers, and the lower quality of the resulting
> > archive, is worth the small increment in speed that is promised. I
> > hope
> 
> 30% *measured* (vs promised) speed increase is nothing to sneer at on
>  low-end cpus like Cortex-A8 is. 

Just to reply to myself:

In libm.so, I took sinf() -a very often used function, absolutely necessary 
for any trig stuff- and tried to actually find the differences using objdump:

on softfp:
$ objdump -S /lib/libm.so.6 --start-address=<startofsinf> --stop-
address=<endofsinf>|grep -c vmov
7

on hardfp:
$ objdump -S /lib/libm.so.6 --start-address=<startofsinf> --stop-
address=<endofsinf>|grep -c vmov
2

Mind you the 2nd vmov in hardfp version, is this:

vmov.f32        s16, s0, 

which definitely does not cost 20 cycles (it's not an mrc instruction).
Do the math, there are 6 more vmov instructions (all between rX and sX 
registers) in the softfp versions. Ok, if one gives a stall of 20 cycles, how 
many cycles do we lose in sinf() alone?

Still not convinced?

Konstantinos