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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
