Re: armelfp: new architecture name for an armel variant
On Thursday 15 July 2010 21:06:52 Paul Brook wrote:
> Not quite. It provides a mechanism for selecting different routines without
> the runtime overhead of a check on every call. It effecitvely provides a
> hook into the dynamaic linker that allows you to decide which function to
> export for a particular symbol. A typical example is to select CPU
> specific implementations of memcpy. You still need to supply all the
> different implementations, and a function to determine which to use.
Er, of course I'd have to supply all the implementations, the difference is
that there is now a proper and common way to do it -anyone who's checked
xine/mplayer/vlc source will know what I mean. Still, it's very good news that
something like this has -at last- been implemented.
> All the implementations must use the same ABI.
Of course. I totally understand that this is not a way to keep softfp/hardfp
versions in the same binary.