tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



On Mon, Nov 11, 2013 at 6:42 PM, Alistair Crooks <agc%pkgsrc.org@localhost> 
wrote:
>
> What I am asking for is a much better way of people describing the
> design decisions they've taken, and for them to attempt the radical
> step of documenting these decisions, and publishing them, so that
> people can understand why these decisions were taken.  This would go a
> long way towards alleviating the WTF moments that we've all been
> experiencing just recently.
>
> To put this another way - someone has a Beaglebone - what userland
> should they be looking for - hf, sf?  Beyond that - earm or arm?  How
> do people find out what chip is in an embedded appliance?  What web
> page documents the choices of ARM NetBSD userland right now, let alone
> how to work out where to get them once they know they want a hf earm?
> How would they specify that in building packages from pkgsrc?
>
> I'm concerned that you think that what we have right now is workable.

earm vs arm is simple, anything that does not have legacy requirements
should use earm.

armhf basically requires VFP support, which has been optional since
ARMv5, and is still technically optional but very widespread (ie all
the other FP alternatives have gone away, there are still some
softfloat machines; NEON is in addition). In Linux world most hardfp
versions also target ARMv7 as well, which caused some annoyance from
the Raspberry pi people so there are also armv6 targetting versions
around. There is almost no *current manufacture* hardware that NetBSD
will currently run on that does not in principle support hardfloat
(that I know of, there is a lot of stuff around of course), as not
putting float in at all seems rare outside microcontrollers now
(unlike MIPS where none of the router type stuff has float). So your
Beaglebone can run hf. Whether it matters I am not sure, I think the
original quotes for the huge speedup were exaggerated for real world
use, but its never going to be slower, and any fp application should
benefit a little.

Justin



Home | Main Index | Thread Index | Old Index