On 11 Nov, 2013, at 15:31 , Justin Cormack <jus...@specialbusservice.com> wrote: > On Mon, Nov 11, 2013 at 10:56 PM, Michael van Elst <mlel...@serpens.de> wrote: >> m...@3am-software.com (Matt Thomas) writes: >> >>> Exactly. with hf, floating point values are passed in floating point >>> registers. That can not be hidden via a library (this works on x86 >>> since the stack has all the arguments). >> >> It could be hidden by emulating the floating point hardware. > > Thats not sane. The slowdown would be enormous. You are emulating > registers as well as operations.
I'm not positive, but isn't this how the original ARM ABI works? I thought the reason they replaced this with the earm ABI is that almost no CPUs of that vintage had floating point units and with eabi the soft float binaries don't have to pay the emulated instruction cost for function calls. And I thought the reason we got earmhf is that most modern processors now have floating point units (though not the same instruction set that the original ABI assumed) but the instructions for copying values between the floating point and integer registers, which get used a lot if you compile hardware floating point with the earm ABI, are abysmally slow (and there aren't a whole lot of integer registers anyway, so the integer argument registers get filled up fast if you are passing doubles). The fact is that the arm instruction set is a moving target and is not always big on backward compatibility. Additionally, the CPUs generally aren't very fast so there's a reason to want to make full, optimal use of the hardware you've got if you can (these CPUs are also frequently used on platforms with almost no file system space, so I wouldn't really want "fat" binaries either). The instructions they keep adding are added because they are useful, so you'd kind of like to take advantage of them if you've got them. All this variety has leaked into the ABI as well. Because of these constraints I'm a fan of how the arm port and arm build system currently works. If you want to build userland binaries that are more or less optimal for the machine you have you can do that. If you want to share userland binaries between different machines you can pick your own least common denominator and build for that. The kernels know what machine they are running on but don't seem to care how the userland code has been compiled. If you are compiling your own binaries you can usually get something close to whatever you'd like. The only problem this creates is if you want to supply prebuilt binaries instead, because there are way too many potential variations, but I personally don't want the solution to this problem to break the things about this port which work really well when you compile your own. I wouldn't mind if the pre-built binaries were organized like this: - There needs to be more than one set of pre-built ARM binaries. Maybe two or three sets for well-chosen targets would be enough to ensure that what you are running isn't wasting too much of your machine. - Each board/platform/kernel should be associated with the userland binaries which are best suited to that machine, and by default kernels should only be built with their best-match userland. This ensures that someone new who picks a particular set of binaries to use will get a userland which makes good use of their machine because the kernel they need for the machine will only be packaged with that userland. - Some attention should be given to figuring out what runs on what. Even if I've compiled the base system for my BeagleBone for earmv7hf myself, it would be nice to still be able to install pkgsrc binaries built for the RPi if that's what is available (though installing pkgsrc binaries built for armv7 on an RPi might not be a good idea). - We should either stop building 'arm' binaries or hide them well so that no one who is starting fresh installs these (when I was looking for a binary distribution to boot on my BeagleBone I could only find 'arm' builds; I built my own instead, but this is not convenient for everyone). If 'arm' == the original ARM ABI there are good reasons why Linux has deprecated that out of existence. Dennis Ferguson