GCC 4.6

Looks like GCC 4.6 is not far off from working.

Here’s a quick dhrystone benchmark compared to gcc 4.1.2

gcc 4.1.2: 1042752.9

gcc 4.6: 1287001.2

gcc 4.6: 1329787.2 with -march=armv7-a -mtune=cortex-a8

Excellent!

Do you know if there’s going to be any effort made to get VFP/NEON working with the C/C++ compiler for the 4.6 release? I know that the pending 4.1.2 release has a version of binutils that supports most/all of the instructions (i.e. you’ll be able to use VFP/NEON from assembler), but it would be good to know whether getting it working with the C compiler is something that’s planned for the next big release. Of course, I still need to hurry up and get the VFPSupport module working first!

The initial start of the GCC 4.6 was surprisingly smooth but only after running its tests and initial fixes it will become clear how far we really are. Note also that 4.6 is still in development by the GCC community so its state can be a bit rough atm.

As for VPF/NEON support, I’m not sure where we will end up. We’ll probably only need to relax our -mfpu checking in our APCS-32 backend (as it is now expecting or even enforcing FPA fpu mode) and then there is a good chance vector operations will work out of the box (by specifying something like ”-mfpu=neon -ftree-vectorize”, possibly with ”-ftree-vectorizer-verbose=1” or higher value for debugging, or use arm_neon.h intrinsics). FP might work as well as long as you refrain from using run-time library calls having one or more float/double parameters or rebuild the run-time library with the same settings (feasible for UnixLib, for SCL probably out of the question).

Of course, doing all this is stretching APCS-32 ABI even further. TBH, I’m more and more questioning whether we should continue with APCS-32 and wondering why we aren’t just adopting AAPCS as is like the rest of the world is using. It would save us reinventing the wheel, have better code (as more registers can be used), a defined path for thumb code support, etc.

FP might work as well as long as you refrain from using run-time library calls having one or more float/double parameters or rebuild the run-time library with the same settings

There’s also the -mfloat-abi=softfp option, which should allow VFP code to be interworked with softfloat libraries, and vice-versa. Could be a useful way of testing features without having to constantly recompile UnixLib.

TBH, I’m more and more questioning whether we should continue with APCS-32 and wondering why we aren’t just adopting AAPCS as is like the rest of the world is using.

I’ve certainly got no objections to adopting AAPCS, although you’d probably need to retain some form of APCS-32 support just for use with the SCL.

I’m happy that VFP/NEON support for GCC is being discussed. Having recently done some testing of VFP/NEON instructions with the RISC OS GCC 4.1, and found that they apparently were not yet supported by the assembler, I was just about to post on the GCC mailing list about whether VFP/NEON was or would be supported in later versions of GCC. Well, this thread made that unnecessary. :)

I’m eager to be able to start using VFP/NEON instructions with GCC (using the inline assembler), as it would make it possible to make things like very efficient vector/matrix libraries.

Naturally, it would be possible to an external assembler to make object files, but that would mean that every operation would incur the overhead of a function call/return, so using the inline assembler (or intrinsics, if they are inlinable) would be preferable.