On Mon, 03 Apr 2006 12:25:17 +0200, peter.kourzanov wrote: >> This may very well be a nauseatingly unworkable suggestion, but for the >> old ABI, it seems to me the most optimal compromise can be achieved if >> everything used a shared-object soft-float library that could be swapped >> out and replaced with whatever work-alike would be most speed-efficient on > > As was explained consistently with my experience, you can not mix > binaries compiled with -mhard-float and with -msoft-float, as well as > ones compiled with -msoft-float -mfpu=vfp with -msoft-float. There is > a flag in the object (look for private flags in objdump -x) that > prevents linking objects with incompatible ABIs.
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. >> the individual machine. The standard library would use basic ARM >> instructions to implement the soft-float API and data types, while one >> drop-in replacement could use FPA instructions to emulate the same thing >> and convert data types on the fly, another could use VFP instructions with >> no conversion, etc. Other ABI inadequacies notwithstanding, is this really >> less trivial to do than replacing the ABI wholesale with something less >> backward-compatible? > > EABI is probably the answer to all those issues... ...except backward compatibility, right? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
