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

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Sun, Nov 10, 2013 at 01:48:12PM -0800, Matt Thomas wrote:
> 
> On Nov 10, 2013, at 1:39 PM, Alistair Crooks <agc%pkgsrc.org@localhost> wrote:
> 
> > On Sun, Nov 10, 2013 at 01:20:41PM -0800, Matt Thomas wrote:
> >> 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).  
> > 
> > Thanks, I understand.  But...  there has to be a different way of
> > doing this that does not require such wholesale changes, especially
> > when they were made without discussion.
> > 
> > + use virtual registers which get mapped onto the real thing, either
> > through compilation or JIT
> 
> Doesn?t help since there are also FP instructions.

Encode the FP instructions in a similar manner, then.
 
> > + optimise for one passing scheme, and translate the other dynamically
> 
> We already have a libc_vfp.so for earm which will use real FP
> instructions to do the softfloat ops.

And this is documented ... where?
 
> > + have both sets of passing conventions in a fat binary, and select
> > accordingly
> 
> ELF doesn?t really support fat binaries.  

ELF doesn't really support versioning, but everyone uses it for that.
 
> > I'm sure there are way more than I've outlined above, and that others
> > have much better ideas than I have.
> > 
> > At the moment, this has been optimised for the kernel architecture,
> > with the userlevel changes assumed to be collateral damage.  Since the
> > users are what matters, that needs to be changed.
> 
> I strongly disagree with that.  I specifically choose use different machine
> arches so that the hard/soft float binary packages would be separate.  
> >From using soft/hard float userlands on PPC, I already knew that mixing
> them was wrong.  

Firstly, you need to publicly document design choices, and get people's
feedback. I suspect that what you've done is the right thing - by keeping
everything secret, though, we have to have these kind of discussions in
retrospect, and there's a lot of ill-will generated, and people wonder
what you were thinking when you did this.

Secondly, you have created new NetBSD ports for each of these hard/soft
float binary packages. They need port maintainers. They need port pages
and mailing lists. They need a whole support ecosystem so that people
know what is out there, what they can use. They need to be added to the
bulk build system, and the regression test systems, assuming they can be
emulated well.

> > How do you propose to fix this (interim) mess for pkgsrc?  This is a
> > real issue for us, and you should send your proposal to
> > tech-pkg%netbsd.org@localhost.
> 
> Is it just the multiplicity of arm packages or something else?

I have no indication before I buy a SoC if it is supported by NetBSD. 
There is no mapping table from SoC to distribution to use.  It is
difficult to see what kernel to use (witness the emails on various
lists which say things don't work for (very talented and clueful
people) when they are using the wrong kernel).  I need to know what
kernel to put on a SoC.  I need to know whether it's earm, and whether
it's sf or hf.  I need to know before I buy that SoC.  I need to know
which SoCs are in which appliance.

So it's not just the large amount of chips out there, it's mapping
them onto NetBSD distributions in advance.

Moving on from that, pkgsrc needs to be updated to deal with all the new
types of hf/sf/earm/arm that people will encounter. I'm more than happy
to work with you to get something that people can use.

Best,
Alistair

Regards,
Alistair