can't find spu_mfcio.h

[IronAvatar]

Can anybody share some light on this issue?

I'm trying to write my first spu prog and for some reason, spu-g++ can't find this header file, even if I add the include path as part of the compiler invocation.

Very odd indeed.

[IronAvatar]

Ok, after a bit of investigation this seems to be something that's going wrong when invoking spu-gcc from make. It works just fine when compiling from the command-line.

Now I'm completely stumped.

[ralferoo]

Is your makefile definitely using spu-gcc? The default would be to compile with gcc unless you define a rule specifically.

An example from my Makefile:

Code: Select all

SPUCC = spu-gcc -std=gnu99 -fpic
SPUCCFLAGS = -O6 -I.

%.s: %.c
        $&#40;SPUCC&#41; $&#40;SPUCCFLAGS&#41; -c -S $< -o $*.s

%.0&#58; %.c
        $&#40;SPUCC&#41; $&#40;SPUCCFLAGS&#41; -c $< -o $*.0

(I often use .0 rather than .o for SPU object files so I can have the files in the same source tree; you might well want to change that. I've also used spu-gcc here, not spu-g++ because I only use C on SPU)

Also, you should be aware that C++ tends to be very greedy with memory. Some people have reported being unable to compile a simple program with an empty main() due to all the libraries g++ pulls in.

[IronAvatar]

Is your makefile definitely using spu-gcc? The default would be to compile with gcc unless you define a rule specifically.

An example from my Makefile:

Code: Select all

SPUCC = spu-gcc -std=gnu99 -fpic
SPUCCFLAGS = -O6 -I.

%.s: %.c
        $&#40;SPUCC&#41; $&#40;SPUCCFLAGS&#41; -c -S $< -o $*.s

%.0&#58; %.c
        $&#40;SPUCC&#41; $&#40;SPUCCFLAGS&#41; -c $< -o $*.0

(I often use .0 rather than .o for SPU object files so I can have the files in the same source tree; you might well want to change that. I've also used spu-gcc here, not spu-g++ because I only use C on SPU)

Also, you should be aware that C++ tends to be very greedy with memory. Some people have reported being unable to compile a simple program with an empty main() due to all the libraries g++ pulls in.

I was actually thinking about trying that last night, but hadn't gotten around to doing it. You're correct in that for some reason, it just wasn't using the spu compiler.

There is a rule in there but there must be something broken, as it seems to be calling ppu-gcc instead of spu-gcc. There must be something faulty in the way that I'm specifying the stems of the rule, so maybe for now, I'll just have all of the spu modules with an extension like .so.

As for the C++ bit...do you mean you're running out of memory while compiling on the PS3? That's a bit worrying because I was wanting to use a shared math library using C++ so I could have more readable code.

Ahh well...maybe I'll have to bite the bullet and find away to build sdl and the X11 libs using the cross-compiler. Also, I'm pretty sure that there's a way to specifiy which libraries to ignroe by default.

[ralferoo]

maybe for now, I'll just have all of the spu modules with an extension like .so.

.so is a really bad idea as it's used for "shared objects" (i.e. libraries). gcc will probably assume a while bunch of options if you use .so.

As for the C++ bit...do you mean you're running out of memory while compiling on the PS3? That's a bit worrying because I was wanting to use a shared math library using C++ so I could have more readable code.

You should have no problems running C++ itself or C++ compiled programs on the PPU. However, if you are targetting the SPU, you might find the C++ runtime takes up too much space. Each SPU only has 256kb of memory.

[IronAvatar]

.so is a really bad idea as it's used for "shared objects" (i.e. libraries). gcc will probably assume a while bunch of options if you use .so.

doh. I hadn't thought about that. Still being a bit new to Linux, I had forgotten all about the extension for shared libraries. Thanks for the heads up on that.

You should have no problems running C++ itself or C++ compiled programs on the PPU. However, if you are targetting the SPU, you might find the C++ runtime takes up too much space. Each SPU only has 256kb of memory.

As I said, I'm pretty sure that you can either tell spu-gcc to ignore a specific library (like llibc++) or atleast to strip out unused symbols in the spu executable. Just because I use features of the language, doesn't mean there needs to be a big load of pre-packed code backing it up.

Well, that's the theory anyhow. Whether this has any baring on reality is another thing all together. Hopefully I'll have time to write a basic vector class and use it in my test spu code and see the sort of memory that the executable takes up tonight.