toolchain for powerpc e500v2
Mon Feb 7 10:40:00 GMT 2011
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?
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
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
More information about the crossgcc