Chris Packham writes: > Hi, > > I have used valgrind (3.2.3 and 3.3.1) successfully on an embedded target with > an e500 processor. My kernel, compiler and libraries are quite different to > those reported but I just wanted to say that it works for me. > > Looking at my ld.so (uClibc implementation) there aren't any vmhaddshs > instructions which may mean that my compiler (gcc 4.1.1 + patches) is not > using > the special e500 instructions or that uClibc doesn't. I'll double check my > compiler flags to see if I'm compiling for e500 or just generic ppc but there > may be a possible workaround. > > Has anyone got some example sourcode that compiles to use this instruction?
I do not think I have source code that generates that particular instruction, but if your gcc was built to support the e500 Signal Processing Extensions (often called SPE, which nicely collides with a certain well-known Power architecture extension) and your assembler recognizes the mnemonics, you should be able to generate a number of them yourself by using the -mspe compiler flag on code that involves floating point operations. You might need a newer gcc than 4.1.x to generate all of the instructions for the e500v2 SPE; and some of them require non-standard calls rather than being generated by gcc's instruction patterns from standard C code. gcc provides an <spe.h> header file that helps applications make those non-standard calls. My guess is that your toolchain wasn't compiled to generate e500 SPE instructions by default, so it uses traditional Power FPU instructions (with kernel emulation) or plain software floating-point. The e500 SPE unit is obnoxious to software on a number of levels: it reuses AltiVec instruction space; it widens the GPRs (R0-R31) to 64 bits to use them as 64-bit-integer/64-bit-float/SIMD-32-bit-float-pair operands; it hijacks the AltiVec exception bit in the Machine Status Register to enable accesses to the top halves of the 64-bit-wide registers; *and* FreeScale says restrict it to libraries and device drivers because SPE will go away in future chips. The only advice I would have for Hiren Gajjar is that it should be possible to generate code that avoids using the SPE by consistently using the -mno-spe compiler flag. (Hopefully that is an acceptable solution, at least when using valgrind.) Michael Poole ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
