Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Tue, Nov 12, 2013 at 6:08 AM, Michael van Elst mlel...@serpens.de wrote:
The slowdown is already enormous due to lack of floating point
hardware. That's why emulating the FP hardware is a very common
way to handle this situation, just look at the other platforms.
The rationale behind this is, that people who use FP operations
in any significant way will use hardware that supports it. And
others will hardly notice the extra slowdown cause by emulation.
The questions are: does ARM support this and is there a usuable
implementation. Linux dropped NWFPE due to licensing issues.
In principle, but the people who have floating point that is not VFP,
so need emulation of registers but can actually do fp might complain.
And people who want to run existing softfloat binaries, probably a
larger group.
Generally people seem happy with a smallish number of userspaces, of Matts list:
earm{v[4567],}{hf,}{eb} except earmv4hf isn’t valid.
The most useful are an old earmv4{eb} and a new earmv6hfe (6 could be
7 here). Thats fewer userspaces than eg are useful on MIPS. The soft
and hard ones can be built and tested on newer hardware as they are
backwards compatible. Almost no software needs fixing to know about
this (just compilers, linkers etc). I don't think this is too terrible
for the best selling CPU platform there is.
Justin
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Nov 12, 2013, at 9:33 AM, Dennis Ferguson dennis.c.fergu...@gmail.com wrote: On 11 Nov, 2013, at 15:31 , Justin Cormack jus...@specialbusservice.com wrote: On Mon, Nov 11, 2013 at 10:56 PM, Michael van Elst mlel...@serpens.de wrote: m...@3am-software.com (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 original arm abi had optional support FPA but netbsd never used it even though we had a FPA emulator. That bitrotted into uselessness since everyone just used softfloat.
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Nov 12, 2013, at 9:33 AM, Dennis Ferguson dennis.c.fergu...@gmail.com wrote: - 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). I’ve been thinking about supporting a “list” of compatible architectures for pkg_add. earmv7hf:earmv6hf:earmhf
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Nov 11, 2013, at 10:08 PM, Michael van Elst mlel...@serpens.de wrote: The slowdown is already enormous due to lack of floating point hardware. That's why emulating the FP hardware is a very common way to handle this situation, just look at the other platforms. The exception handling is much costlier than doing a softfloat call. It’s also adding kernel bloat.
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
m...@3am-software.com (Matt Thomas) writes: On Nov 11, 2013, at 10:08 PM, Michael van Elst mlel...@serpens.de wrote: The slowdown is already enormous due to lack of floating point hardware. That's why emulating the FP hardware is a very common way to handle this situation, just look at the other platforms. The exception handling is much costlier than doing a softfloat call. You missed the second paragraph. Its also adding kernel bloat. Indeed, a little bit of kernel bloat compared to a dozen userlands and a dozen package repositories that require building and testing.
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Nov 12, 2013, at 11:47 AM, Michael van Elst mlel...@serpens.de wrote: m...@3am-software.com (Matt Thomas) writes: On Nov 11, 2013, at 10:08 PM, Michael van Elst mlel...@serpens.de wrote: The slowdown is already enormous due to lack of floating point hardware. That's why emulating the FP hardware is a very common way to handle this situation, just look at the other platforms. The exception handling is much costlier than doing a softfloat call. You missed the second paragraph. No I didn’t. It’s also adding kernel bloat. Indeed, a little bit of kernel bloat compared to a dozen userlands and a dozen package repositories that require building and testing. There are a lot of floating point and load/store instruction variants on ARM. It’s not “a little bit” of code, it’s a lot. I have from http://mail-index.netbsd.org/port-powerpc/2012/09/26/msg003275.html On a P2020, a build.sh distribution for evbppc took 6.2% less time on a softfloat userland .vs. hardfloat userland with kernel-emulation. 10h55m32s (soft) vs. 11h38m50s (hard) Doing a release build is not a floating point intensive workload yet it incurred a significant amount of overhead. The platforms without FP are going to be the slowest so emulating FP would make then even slower. When it comes to building a system I am willing to incur a slower build or consume more resources in order to get a faster system. Spend the time upfront to get things to as fast as possible. My builds might be slower or needs more space for packages, but the resultant system will run faster. That seems to be a tradeoff worth making.
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Nov 12, 2013, at 2:06 PM, Matt Thomas m...@3am-software.com wrote: On Nov 11, 2013, at 10:08 PM, Michael van Elst mlel...@serpens.de wrote: The slowdown is already enormous due to lack of floating point hardware. That's why emulating the FP hardware is a very common way to handle this situation, just look at the other platforms. The exception handling is much costlier than doing a softfloat call. It’s also adding kernel bloat. I agree. Another example of bit rot is the analogous MIPS feature -- which is not even close to competitive with softfloat functionally, never mind on performance. paul
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Mon, Nov 11, 2013 at 02:23:11PM -0500, Thor Lancelot Simon wrote: It seems to me this is largely a tempest in a teapot that could be dealt with by a simple table, somewhere obvious on the web site, showing the mapping necessary to download a working kernel and binaries for each common CPU (or SoC). And that table is... where, exactly? My point is that this should have been done first. A simple list of mappings, kept up to date by the people who work on or commit this stuff. Not difficult, and immensely helpful to anyone trying to use NetBSD for anything. In lieu of that, the whole arm hf/sf setup just stinks from a usability PoV. NetBSD isn't alone in this - Linux is going through this whole thing too, but at least the goal of the strategy there appears coherent. We had nothing documented here until this tempest in a teapot was brewed - we have only had a list of the possible variants in the last day or so. This sucks, and has to change. Much more communication needed. Regards, Alistair
