Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 11 Nov, 2013, at 15:31 , Justin Cormack 
<justin%specialbusservice.com@localhost> wrote:
> On Mon, Nov 11, 2013 at 10:56 PM, Michael van Elst 
> <mlelstv%serpens.de@localhost> wrote:
>> matt%3am-software.com@localhost (Matt Thomas) writes:
>> 
>>> Exactly.  with hf, floating point values are passed in floating point
>>> registers.  That can not be hidden via a library (this works on x86
>>> since the stack has all the arguments).
>> 
>> It could be hidden by emulating the floating point hardware.
> 
> Thats not sane. The slowdown would be enormous. You are emulating
> registers as well as operations.

I'm not positive, but isn't this how the original ARM ABI works?
I thought the reason they replaced this with the earm ABI is that
almost no CPUs of that vintage had floating point units and with
eabi the soft float binaries don't have to pay the emulated
instruction cost for function calls.  And I thought the reason we
got earmhf is that most modern processors now have floating point
units (though not the same instruction set that the original ABI
assumed) but the instructions for copying values between the floating
point and integer registers, which get used a lot if you compile
hardware floating point with the earm ABI, are abysmally slow (and
there aren't a whole lot of integer registers anyway, so the integer
argument registers get filled up fast if you are passing doubles).

The fact is that the arm instruction set is a moving target and is
not always big on backward compatibility.  Additionally, the CPUs
generally aren't very fast so there's a reason to want to make full,
optimal use of the hardware you've got if you can (these CPUs are
also frequently used on platforms with almost no file system space,
so I wouldn't really want "fat" binaries either).  The instructions
they keep adding are added because they are useful, so you'd kind
of like to take advantage of them if you've got them.  All this
variety has leaked into the ABI as well.

Because of these constraints I'm a fan of how the arm port and arm
build system currently works.  If you want to build userland binaries
that are more or less optimal for the machine you have you can do that.
If you want to share userland binaries between different machines you
can pick your own least common denominator and build for that.  The
kernels know what machine they are running on but don't seem to care
how the userland code has been compiled.  If you are compiling your
own binaries you can usually get something close to whatever you'd
like.  The only problem this creates is if you want to supply prebuilt
binaries instead, because there are way too many potential variations,
but I personally don't want the solution to this problem to break the
things about this port which work really well when you compile your own.

I wouldn't mind if the pre-built binaries were organized like this:

- There needs to be more than one set of pre-built ARM binaries.  Maybe
  two or three sets for well-chosen targets would be enough to ensure
  that what you are running isn't wasting too much of your machine.

- Each board/platform/kernel should be associated with the userland
  binaries which are best suited to that machine, and by default kernels
  should only be built with their best-match userland.  This ensures
  that someone new who picks a particular set of binaries to use will
  get a userland which makes good use of their machine because the kernel
  they need for the machine will only be packaged with that userland.

- Some attention should be given to figuring out what runs on what.  Even
  if I've compiled the base system for my BeagleBone for earmv7hf myself,
  it would be nice to still be able to install pkgsrc binaries built for
  the RPi if that's what is available (though installing pkgsrc binaries
  built for armv7 on an RPi might not be a good idea).

- We should either stop building 'arm' binaries or hide them well so that
  no one who is starting fresh installs these (when I was looking for a
  binary distribution to boot on my BeagleBone I could only find 'arm'
  builds; I built my own instead, but this is not convenient for everyone).
  If 'arm' == the original ARM ABI there are good reasons why Linux has
  deprecated that out of existence.

Dennis Ferguson