On Thu, Jul 15, 2010 at 10:26 AM, Paul Brook <p...@codesourcery.com> wrote: >> On Thu, Jul 15, 2010 at 03:47:33PM +0100, Paul Brook wrote: >> > > armel can also use vfp instructions, so I personally find it >> > > confusing. >> > Yes, however fixing this this does not require a new port. It only >> > requires providing alternative packages builds within the same port. The >> > important point being that (assuming capable hardware) you can freely >> > mix the two. >> >> It sounded so far like you can't. If a library expects softfloat then >> you can't call it from a hardfloat binary since the calling convension >> is different. They are about as compatible as i386 and amd64 in that >> case. Sure both can run on an amd64 kernel and cpu, both can be on one >> system, but they really aren't mixed together. > > Enabling use of VFP does not require use of the hard-float ABI. Please don't > confuse the two.
Hi Paul, The whole point of the port is that we get rid of the softfloat ABI in order to use the VFP unit without playing around moving registers around. This sort of came about from Konstantinos' porting of the Eigen2 library (after he had done it for AltiVec) to NEON and some of the developers noticed it wasn't so much faster because gcc inserts what can only be described as evil between the start of the function and the real meat of the code. The pipeline stalls for register movement are noticable in real code as a 20% or higher performance hit. It makes the entire process of using an FPU or NEON kind of a chore, to implement an optimization and see all the benefits removed because of the design of the ABI allowing FPU emulation. Your best option is then to force inline everything and hope for the best. I think I pointed out in the wiki, and I think it was Martin who did the test, while the ARM EABI docs say that generated objects from the compiler have the build information embedded into them, and any compiler (including your version :) will refuse to link together softfp and hardfp objects, somehow this information is lost in the translation to ELF, or ld.so does not bother to check, so a hardfp, linked, stripped or unstripped executable can be linked successfully with a softfp linked, stripped or unstripped dynamic shared object. And this causes something approaching you expect a function to work on FPU arguments but the hardfp executable is operating on FPU registers and the softfp library expects it to be in the integer registers. The work is done but they're looking in the wrong places. I think that checking needs to be looked at somewhere, and I think that's something Codesourcery are good at :) Until that fix goes in the only consideration right now is that you shouldn't be able to even install - without a massive warning from the packager - a hardfloat binary on top of a softfloat system or vice versa - since every dependency needs to be compiled using the same ABI. What would not be so great is that even if it was fixed, the option to use a faster floating point ABI drags in a clone of every package on your system (at the very least, libc, libm, and all the system library dependencies) increasing the size of the installed system. If you can guarantee you're running on a system with certain minimum requirements it makes a lot of sense to design the OS to those certain minimum requirements. armel covers the ones that don't match up, and uses softfp to basically bridge the gap between running a system with FPU vs one without, and selecting the FPU capabilities and loading the right libraries as a matter of course. The same will be true of the new port: but VFPv3-D16 is guaranteed, hard float ABI is guaranteed, and things like NEON or fp16 are loaded automatically depending on capabilities. What it does is increases performance while reducing the installed footprint of the system. -- Matt Sealey <m...@genesi-usa.com> Product Development Analyst, Genesi USA, Inc. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktilxmuy-u7_gyv0c0yllymtxzb8snomhpatx7...@mail.gmail.com
