Re: Deciding new arm EABI port name
Daniel Gimpelevich wrote:
On Tue, 04 Apr 2006 12:43:29 +0300, Riku Voipio wrote:
On Mon, Apr 03, 2006 at 10:28:29AM -0700, Daniel Gimpelevich wrote:
That is precisely why I am suggesting here that -mhard-float be dumped
altogether in favor of -msoft-float, but have the soft-float
implementation code be a shared object that can be replaced as needed.
..which would break backward compatability with current hardfloat libs
and binaries.
That's only software compatibility, and AFAICT the kernel doesn't care and
will happily run both types of binaries.
What is the kernel in your view, btw? AFAICT it is still software;-)
Yes, but for -hard-float in absence of FPU it needs to provide emulation.
Also, it should support EABI...
But the point is that all currently existing binaries are built with
-mhard-float.
Which is the point I am trying to address with 'arm-softfloat'
architecture. It
seem to work OK (gcc-4.0.3, glibc-2.3.6-4, lots of packages including
mplayer &co).
Had to tweak a bit in glibc and gcc to get corrrect libfloat.a though...
EABI is probably the answer to all those issues...
...except backward compatibility, right?
well, changing from -mhard-float to -msoft-float breaks backward
compatablity too. Vincent Sanders had similar (but more sophisticated)
transition plan, but turned out to be unimplementable because current
hardfloat ABI, float return values are returned a fpu register.
OK, I found his post of 2005-09-29, and the plan seems to be largely a
chronological inversion of the idea that I have, with inevitable
chicken-and-egg issues in addition to the aforementioned ABI roadblocks.
Furthermore, he stated that the purpose of the plan was avoidance of what
I see as the real problem: the non-feasibility of dumping all built
binaries and starting from scratch. If sections of the archive could be
rebuilt with -msoft-float in stages, with binaries of different ABIs that
don't link together coexisting for a time, I think the impact of dumping
all built binaries could be made more palatable.
My preference would be the introduction of a new 'arm-softfloat'
architecture.
Besides, EABI has actually been implemented, while a hardfloat
libfloat is still at a idea stage.
Correct, but a softfloat libfloat is also a reality today, and can easily
be a shared object. Once all binaries use it, attention can be turned to
crafting drop-in hardfloat replacements for it that use the softfloat ABI.
The only real question as I see it would be whether such a gradual
replacement of all built binaries could be OK when a sudden need to
rebuild all of them is not.
Still not 100% optimal - overhead of a function call in a (dynamically)
linked libfloat per each FPU instruction...
Isn't EABI the answer to this? From what I understood, you can mix
binaries compiled with hard- and soft-float if you also add -mabi=eabi.
Pjotr Kourzanov.
Reply to: