Because the Debian stable version (squeeze) only supports ARM using the ARMv4+ softfloat ABI (armel), and this is the distro that the 'official' Debian image available from http://www.raspberrypi.org/downloads uses.Burngate wrote:And since all Pis have one, why bother with softfloat at all?
This is actually one of the "good" reasons to have softfp and softfloat support. If hardware changes and no one has ported in the support you can atleast run a slower version using software. Also if you are building a general purpose system you can sacrifice some speed for larger support.AndrewS wrote:Because the Debian stable version (squeeze) only supports ARM using the ARMv4+ softfloat ABI (armel), and this is the distro that the 'official' Debian image available from http://www.raspberrypi.org/downloads uses.Burngate wrote:And since all Pis have one, why bother with softfloat at all?
The Debian unstable version (wheezy) adds an ARMv7+ hardfloat ABI port (armhf), but this won't run on the ARMv6 CPU used by the RaspberryPi. So to "fill in the gap" the Raspbian project http://raspbian.com/RaspbianFAQ is currently in the process of recompiling/porting every Debian package in wheezy to use the ARMv6 hardfloat available on the RaspberryPi
At least, that's the way I understand it
Personally I think your analogies are confusing and I also belive your post contains some misconceptions.As a very simplistic explanation:
That was what the old debian arm port (not armel or armhf) did. Unfortunately there were two problemsOnce long ago I knew something about ARM on my RiscPC. If memory serves, you could put in FPU instructions, which without a FPU would call the instruction exception vector and thence into the Floating-Point Emulator. (The strongarm never had a FPU)
So if the relevent libraries include a FPE, calling it only involves a couple of instruction cycles even if our target hardware doesn't have a FPU
Not true, code compiled with 'softfp' uses floating-point instructions and can only be run on a system with an fpu. But it can be linked with code (or libraries, be they static or dynamic) that was compiled woth 'soft'. So softfp supplies the best case of interoperability for library linking. If you actually have the fpu, you want as much of your code as possible compiled with 'softfp', but if some of the libraries are generic and are compiled with 'soft' it will still work. There is relatively little speed difference between 'hard' and 'softfp', unless you are calling a lot of very small functions which are passing floating point values as parameters or returning them. In most cases the extra overhead of 'softfp' will be minimal compared to the time actually doing computations.So when you see that softfp is compatible with softfloat it means that the system will decide if it can (and some cases should) use a hardware FPU
Users browsing this forum: Google [Bot] and 24 guests