Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
Hi, On Tue, Nov 12, 2013 at 07:47:20PM +, Michael van Elst wrote: > m...@3am-software.com (Matt Thomas) writes: > > > >On Nov 11, 2013, at 10:08 PM, Michael van Elst 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. Yes - I didn't measure current arms in that respect, but I did try to add the M68060 missing FP instruction emulation package to libm and compare to the kernel trap version a couple of years ago. The kernel trap version turned out to be faster - I guessed because of less (physically indexed) cache trashing. -is -- seal your e-mail: http://www.gnupg.org/
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
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Tue, Nov 12, 2013 at 01:25:31PM -0800, Matt Thomas wrote: > > 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. I agree. This set of platforms are mostly embedded systems, some very small, and there in particular, I think this tradeoff is the right one to make. Thor
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Nov 12, 2013, at 2:06 PM, Matt Thomas wrote: > > On Nov 11, 2013, at 10:08 PM, Michael van Elst 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 Nov 12, 2013, at 11:47 AM, Michael van Elst wrote: > m...@3am-software.com (Matt Thomas) writes: > > >> On Nov 11, 2013, at 10:08 PM, Michael van Elst 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]
m...@3am-software.com (Matt Thomas) writes: >On Nov 11, 2013, at 10:08 PM, Michael van Elst 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 11, 2013, at 10:08 PM, Michael van Elst 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]
On Nov 12, 2013, at 9:33 AM, Dennis Ferguson 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 12, 2013, at 9:33 AM, Dennis Ferguson wrote: > > On 11 Nov, 2013, at 15:31 , Justin Cormack > wrote: >> On Mon, Nov 11, 2013 at 10:56 PM, Michael van Elst >> 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 11 Nov, 2013, at 15:31 , Justin Cormack wrote: > On Mon, Nov 11, 2013 at 10:56 PM, Michael van Elst 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 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
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Tue, Nov 12, 2013 at 6:08 AM, Michael van Elst 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]
jus...@specialbusservice.com (Justin Cormack) writes: >On Mon, Nov 11, 2013 at 10:56 PM, Michael van Elst 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. 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.
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Nov 11, 2013, at 8:33 PM, Warner Losh wrote:
> Is there a complete write up of the conventions here?
Conventions?
earm{v[4567],}{hf,}{eb} except earmv4hf isn’t valid.
Due to recent GCC changes, the earmv6* and earmv7* not only will have
instructions that execute on pre-armv6 CPUs they will do unaligned accesses
which will handled by the CPU transparently. These unaligned accesses are not
supported by pre-armv6 CPUs.
That’s yet another ABI permutation. The kernel could fix them up but at
significant cost.
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Nov 11, 2013, at 4:31 PM, Justin Cormack wrote: > On Mon, Nov 11, 2013 at 10:56 PM, Michael van Elst 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. Is there a complete write up of the conventions here? Warner
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Mon, Nov 11, 2013 at 10:56 PM, Michael van Elst 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. Justin
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
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.
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Mon, Nov 11, 2013 at 6:42 PM, Alistair Crooks 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
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Mon, Nov 11, 2013 at 08:01:15PM +0100, Alistair Crooks wrote: > > I have no indication before I buy a SoC if it is supported by NetBSD. I can't see how this, at least, is any worse than it was before. At the end of the day, either we're going to use the absolute LCD feature set for any architecture with multiple generations -- which would leave us running 32-bit MIPS1 code on Octeon, etc. just for the convenience of having "only one userland MIPS port" or we're going to have this kind of profusion of ports per CPU family. It's just a fact of life. ARM in particular, but also MIPS and to some extent PowerPC, have far more variants than our old scheme accounted for. To actually be able to use the features of those variants, there will have to be many more sets of userland binaries. We can pretend otherwise, and get lousy performance and lots of confusion from people building embedded things that actually need the features, or we can bite the bullet and admit there really cannot be a single set of "arm" binaries any longer. 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). Thor
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Sun, Nov 10, 2013 at 01:48:12PM -0800, Matt Thomas wrote: > > On Nov 10, 2013, at 1:39 PM, Alistair Crooks 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-...@netbsd.org. > > 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
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Mon, Nov 11, 2013 at 10:18:29AM -0500, Thor Lancelot Simon wrote: > On Sun, Nov 10, 2013 at 08:38:27PM +0100, Alistair Crooks wrote: > > > > But in the big picture, having hf and sf versions of a platform's > > userland, in the year 2013, is, well, sub-optimal. I don't think the > > That seems wrong to me. I don't think in this cases you have > "a platform" -- you have two platforms that happen to be able to run > some of the same code, but which do not share an ABI. > > To put it this way, NetBSD on mips can run Ultrix binaries. Should > we simply declare Ultrix ECOFF the lowest common denominator and run > everything else in emulation rather than native? Not sure I follow your logic there - certainly not saying that we should do that. 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. Regards, Alistair
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Sun, Nov 10, 2013 at 08:38:27PM +0100, Alistair Crooks wrote: > > But in the big picture, having hf and sf versions of a platform's > userland, in the year 2013, is, well, sub-optimal. I don't think the That seems wrong to me. I don't think in this cases you have "a platform" -- you have two platforms that happen to be able to run some of the same code, but which do not share an ABI. To put it this way, NetBSD on mips can run Ultrix binaries. Should we simply declare Ultrix ECOFF the lowest common denominator and run everything else in emulation rather than native? Thor
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Nov 10, 2013, at 2:24 PM, Justin Cormack wrote: > On Sun, Nov 10, 2013 at 9:48 PM, Matt Thomas wrote: >> 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. > > Whats so wrong with it? that i never considered the userlevel problems when I made the choice for a separate MACHINE_ARCH. I made the decision precisely for userlevel concerns. The kernel doesn’t care at all.
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Sun, Nov 10, 2013 at 9:48 PM, Matt Thomas wrote: > 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. Whats so wrong with it? Justin
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Nov 10, 2013, at 1:39 PM, Alistair Crooks 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. > + 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. > + have both sets of passing conventions in a fat binary, and select > accordingly ELF doesn’t really support fat binaries. > 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. > 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-...@netbsd.org. Is it just the multiplicity of arm packages or something else?
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
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 + optimise for one passing scheme, and translate the other dynamically + have both sets of passing conventions in a fat binary, and select accordingly 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. 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-...@netbsd.org. Thanks, Alistair
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
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). Not exactly true. Floating point values are returned via registers on i386 as well. Joerg
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Nov 10, 2013, at 12:57 PM, Justin Cormack wrote: > On Sun, Nov 10, 2013 at 7:38 PM, Alistair Crooks wrote: >> On Sun, Nov 10, 2013 at 04:56:04AM +, Jun Ebihara wrote: >>> Module Name: pkgsrc >>> Committed By: jun >>> Date: Sun Nov 10 04:56:04 UTC 2013 >>> >>> Modified Files: >>> pkgsrc/misc/raspberrypi-userland: Makefile >>> >>> Log Message: >>> support earmhf. >>> ONLY_FOR_PLATFORM= NetBSD-*-*arm* >>> oked by jmcneill. >> >> Thanks for doing this, Jun-san. >> >> But in the big picture, having hf and sf versions of a platform's >> userland, in the year 2013, is, well, sub-optimal. I don't think the >> ramifications of the change were considered in enough detail, and we >> need to discuss it, before we have to start growing new architectures >> in pkgsrc for this and that. >> >> Can't we lean on what was done for i386/i387 twenty years ago, and >> use a userland library to decide whether to use softfloat in the >> absence of hardware? >> >> So let's discuss... > > armhf is not just about whether there is or is not hardfloat, it is > also a different ABI. Its more like mips o32 vs n32 in that it is an > ABI change that requires some hardware requirements too. 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).
Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Sun, Nov 10, 2013 at 7:38 PM, Alistair Crooks wrote: > On Sun, Nov 10, 2013 at 04:56:04AM +, Jun Ebihara wrote: >> Module Name: pkgsrc >> Committed By: jun >> Date: Sun Nov 10 04:56:04 UTC 2013 >> >> Modified Files: >> pkgsrc/misc/raspberrypi-userland: Makefile >> >> Log Message: >> support earmhf. >> ONLY_FOR_PLATFORM= NetBSD-*-*arm* >> oked by jmcneill. > > Thanks for doing this, Jun-san. > > But in the big picture, having hf and sf versions of a platform's > userland, in the year 2013, is, well, sub-optimal. I don't think the > ramifications of the change were considered in enough detail, and we > need to discuss it, before we have to start growing new architectures > in pkgsrc for this and that. > > Can't we lean on what was done for i386/i387 twenty years ago, and > use a userland library to decide whether to use softfloat in the > absence of hardware? > > So let's discuss... armhf is not just about whether there is or is not hardfloat, it is also a different ABI. Its more like mips o32 vs n32 in that it is an ABI change that requires some hardware requirements too. Justin
hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]
On Sun, Nov 10, 2013 at 04:56:04AM +, Jun Ebihara wrote: > Module Name: pkgsrc > Committed By: jun > Date: Sun Nov 10 04:56:04 UTC 2013 > > Modified Files: > pkgsrc/misc/raspberrypi-userland: Makefile > > Log Message: > support earmhf. > ONLY_FOR_PLATFORM= NetBSD-*-*arm* > oked by jmcneill. Thanks for doing this, Jun-san. But in the big picture, having hf and sf versions of a platform's userland, in the year 2013, is, well, sub-optimal. I don't think the ramifications of the change were considered in enough detail, and we need to discuss it, before we have to start growing new architectures in pkgsrc for this and that. Can't we lean on what was done for i386/i387 twenty years ago, and use a userland library to decide whether to use softfloat in the absence of hardware? So let's discuss... Thanks, Alistair PS. I'm going to take a lack of response to this mail (by Nov 18th) to indicate that the hf/sf stuff should be backed out. All interested parties please respond. Thanks!
