Re: toolchain for powerpc e500v2

[David Brown <david at westcontrol dot com>]

On 06/02/2011 12:48, Titus von Boxberg wrote:
> Hi all,
>
> I'm trying to use ct-ng (of approx. May 2010) to generate
> cross gcc-4.5.1, glibc-2.9/linux for a powerpc e500v2 / SPE.
>
> Setting floating point to "hardware" results in a build
> error in glibc where the assembler complains while compiling
> an FP file about an unmatched constraint
> (I could try to get the original message if it helps).
>
> The tool chain gets built when I set floating point support to "software".
> However, the resulting compiler does not emit hardware FP instructions
> unless I give -mhard-float on the command line.
>
> Is my assumption correct that setting floating point to "hardware" turns on
> code generation for the standard PowerPC FPU which this target lacks?
>
> I'd like to avoid having a compiler which needs target specific flags
> on the command line, thus:
> Does anyone know which options to turn on to get a compiler that
> emits correct SPE FP instructions without explicitly being told so
> by -mhard-float?
>
> Regards
> Titus


The SPE floating point support is not standard PPC hardware floating 
point, and uses totally different instructions.  If you try to use 
-mhard-float, either as a command-line switch or by default in the 
build, things are going to go badly wrong, as it will generate PPC 
floating point instructions that are not implemented on the e500v2.

I would look at the CodeSourcery toolchain.  They have support for SPE 
floating point in current releases, which you can get as source or 
pre-build binary.  I don't know whether this support has made it into 
the mainline FSF trees as yet (call me lazy, but I've just used the 
binaries from CodeSourcery), but if not then I'm sure it will 
eventually.  It requires particular flags to enable the SPE floating 
point - it may be possible to build your own version that uses it by 
default.

Remember that the SPE only supports single-precision floating point - be 
very careful to avoid doubles in your code (or use flags to force 32-bit 
"doubles").  It's easy to write "x = y * 1.5" instead of "x = y * 1.5f", 
and give your cpu a great deal more work.


Personally, I disagree with your aim of avoiding compiler switches for 
the target - I consider compiler switches in the makefile as part of the 
source code, and would rather state them explicitly there than rely on a 
custom-built compiler.  But that's a matter of choice.


--
For unsubscribe information see http://sourceware.org/lists.html#faq