Does your library have to be a single compiled binary across all these variants? If so, good luck...
Otherwise, hopefully, a compiler takes care of most of the mess for you and gets you the best it can on the platform you're targeting. You might need to check that things would run on a variety of configurations - for instance hardfloat and softfloat do indeed have very different performance profiles when it comes to floats. Thumb shouldn't bother you too much as an application programmer (unless I'm very much mistaken) because it's just another instruction set for a compiler to target.
Errr....
You can get into all sorts of complications when actually looking at the platform ABIs. Debian, for instance, seem to have something of a lowest-common-denominator approach that targets features present everywhere. Which is then why someone had to rebuild it to get decent FP performance out of the Raspberry Pi which had hard-float...
Part of the complexity is that ARM is a licensed architecture. Some companies license the design of the whole core, some incorporate their own stuff and some just license the instruction set and do their own stuff otherwise.
What do you mean 'supported across all (or most) ARM cores'? Because that's huge and varies massively. There are the sub-100MHz embedded devices I happen to be working on at the moment (which may be running any of a load of different OSs), there are ARM cores embedded in all sorts of controllers where I wouldn't think you'd want to run, then there's the multi-core multi-GHz stuff from the likes of Samsung, Qualcomm and Marvell...
" Debian, for instance, seem to have something of a lowest-common-denominator approach that targets features present everywhere."
Debian actually has three ARM ports in progress.
ArmEabiPort - newer port using the "new" ABI (EABI), supported on ARM v4t and higher. First released with 5.0 (Lenny). GNU Triplet: arm-linux-gnueabi
ArmHardFloatPort - the latest 32-bit port, using the hard-float version of the "new" ABI (EABI), targetting ARM v7 and up. To be released with 7.0 (Wheezy). GNU Triplet: arm-linux-gnueabihf
Arm64Port - the latest port, for the 64-bit ARMv8 architecture. Likely to be released with 8.0 (Jessie). GNU Triplet: aarch64-linux-gnu
> Does your library have to be a single compiled binary across all these variants?
No no, not that. :)
As Matt mentioned my work does include JIT compilers, so I'm curious to know how many instruction variants I'd have to support. But I also want to simply test that my plain C code (ie. the interpreted, slow paths) doesn't make any platform-specific assumptions that break on some processors.
> What do you mean 'supported across all (or most) ARM cores'?
My intention is that anyone can compile my library out-of-the-box and have it just work, unless their CPU has a fundamental limitation that I can't support. So far the only such limitation I want to concede is that I require at least a 32-bit CPU (for one, my program's code and data will only barely fit in 64k of RAM, and wouldn't leave much space for anything else).
I know that some of haberman's libraries (like upb) include JIT compilers. In those cases you can't just rely on the compiler to take care of instruction set differences. (I'm on the mobile Firefox team, and we run into similar issues targeting our JavaScript engine to different ARM flavors.)
Then that very well could turn out to be a complete nightmare!
Yes, if you're in the business of writing compilers - traditional, JIT or otherwise - then you're going to hit all sorts of issues with this stuff, and rapidly head off beyond the realms in which I have anything useful to say :)
Otherwise, hopefully, a compiler takes care of most of the mess for you and gets you the best it can on the platform you're targeting. You might need to check that things would run on a variety of configurations - for instance hardfloat and softfloat do indeed have very different performance profiles when it comes to floats. Thumb shouldn't bother you too much as an application programmer (unless I'm very much mistaken) because it's just another instruction set for a compiler to target.
Errr....
You can get into all sorts of complications when actually looking at the platform ABIs. Debian, for instance, seem to have something of a lowest-common-denominator approach that targets features present everywhere. Which is then why someone had to rebuild it to get decent FP performance out of the Raspberry Pi which had hard-float...
Part of the complexity is that ARM is a licensed architecture. Some companies license the design of the whole core, some incorporate their own stuff and some just license the instruction set and do their own stuff otherwise.
What do you mean 'supported across all (or most) ARM cores'? Because that's huge and varies massively. There are the sub-100MHz embedded devices I happen to be working on at the moment (which may be running any of a load of different OSs), there are ARM cores embedded in all sorts of controllers where I wouldn't think you'd want to run, then there's the multi-core multi-GHz stuff from the likes of Samsung, Qualcomm and Marvell...