Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
On Thu, Jul 15, 2010 at 10:26 AM, Paul Brook <paul@codesourcery.com> wrote:
>> On Thu, Jul 15, 2010 at 03:47:33PM +0100, Paul Brook wrote:
>> > > armel can also use vfp instructions, so I personally find it
>> > > confusing.
>> > Yes, however fixing this this does not require a new port. It only
>> > requires providing alternative packages builds within the same port. The
>> > important point being that (assuming capable hardware) you can freely
>> > mix the two.
>>
>> It sounded so far like you can't. If a library expects softfloat then
>> you can't call it from a hardfloat binary since the calling convension
>> is different. They are about as compatible as i386 and amd64 in that
>> case. Sure both can run on an amd64 kernel and cpu, both can be on one
>> system, but they really aren't mixed together.
>
> Enabling use of VFP does not require use of the hard-float ABI. Please don't
> confuse the two.
Hi Paul,
The whole point of the port is that we get rid of the softfloat ABI in
order to use the VFP unit without playing around moving
registers around. This sort of came about from Konstantinos' porting
of the Eigen2 library (after he had done it for AltiVec)
to NEON and some of the developers noticed it wasn't so much faster
because gcc inserts what can only be described as
evil between the start of the function and the real meat of the code.
The pipeline stalls for register movement are noticable
in real code as a 20% or higher performance hit.
It makes the entire process of using an FPU or NEON kind of a chore,
to implement an optimization and see all the benefits
removed because of the design of the ABI allowing FPU emulation. Your
best option is then to force inline everything and hope
for the best.
I think I pointed out in the wiki, and I think it was Martin who did
the test, while the ARM EABI docs say that generated
objects from the compiler have the build information embedded into
them, and any compiler (including your version :) will
refuse to link together softfp and hardfp objects, somehow this
information is lost in the translation to ELF, or ld.so does
not bother to check, so a hardfp, linked, stripped or unstripped
executable can be linked successfully with a softfp
linked, stripped or unstripped dynamic shared object. And this causes
something approaching you expect a function to
work on FPU arguments but the hardfp executable is operating on FPU
registers and the softfp library expects it to be in
the integer registers. The work is done but they're looking in the wrong places.
I think that checking needs to be looked at somewhere, and I think
that's something Codesourcery are good at :)
Until that fix goes in the only consideration right now is that you
shouldn't be able to even install - without a massive
warning from the packager - a hardfloat binary on top of a softfloat
system or vice versa - since every dependency
needs to be compiled using the same ABI.
What would not be so great is that even if it was fixed, the option to
use a faster floating point ABI drags in a clone of
every package on your system (at the very least, libc, libm, and all
the system library dependencies) increasing the
size of the installed system. If you can guarantee you're running on a
system with certain minimum requirements it
makes a lot of sense to design the OS to those certain minimum
requirements. armel covers the ones that don't
match up, and uses softfp to basically bridge the gap between running
a system with FPU vs one without, and selecting
the FPU capabilities and loading the right libraries as a matter of
course. The same will be true of the new port: but
VFPv3-D16 is guaranteed, hard float ABI is guaranteed, and things like
NEON or fp16 are loaded automatically
depending on capabilities. What it does is increases performance while
reducing the installed footprint of the system.
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
Reply to: