Re: Deciding new arm EABI port name
On Tue, 04 Apr 2006 13:30:24 +0200, Pjotr Kourzanov wrote:
> Daniel Gimpelevich wrote:
>
>> [quoted text muted]
> What is the kernel in your view, btw? AFAICT it is still software;-)
It's software that's already compatible with -mhard-float and
-msoft-float. Wouldn't the kernel need to be recompiled for EABI?
> Yes, but for -hard-float in absence of FPU it needs to provide emulation.
Right, that should not go away, in case old binaries get stuck somewhere
in the filesystem.
> Also, it should support EABI...
>
> But the point is that all currently existing binaries are built with
> -mhard-float.
That's the biggest problem to address with the existing archive.
> 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...
That's great, but having two architectures with identical kernels
redefines "architecture" in a way that would best be avoided.
>> [quoted text muted]
> My preference would be the introduction of a new 'arm-softfloat'
> architecture.
Just so that everything old would be new again? Seems like that's trying
to solve more problems than there are. Also, recent technological history
is littered with attempts at future-proofing that caused more difficulty
in the long run. EABI may warrant being designated a separate arch, but
this?
>> [quoted text muted]
> Still not 100% optimal - overhead of a function call in a (dynamically)
> linked libfloat per each FPU instruction...
Being 100% optimal isn't exactly the most worthy goal here. Coming as
close as possible to 100% while still having a sane number of sets of
binaries is a more sensible goal.
> 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.
Apparently, that has a cost in hardware backward compatibility.
Reply to: