Re: [Valgrind-users] ppc e500 - declined to decode an AltiVec insn - vmhaddshs

[Hiren G. <hir...@ya...>]

Hi Poole,

   Thanks for the help. Sorry, I could understand bits and pieces here and there, but I couldn't follow what you mentioned 100% since, I lack knowledge of such low levels. 

   However, using -mno-spe might not work since, the issue is not in the APP code, but its in the LD. At first place, I did not know how that symbol is getting loaded in LD. Besides, I have tried compiling app with -mno-spe but it seems my compiler does not recognize it. Also, it won't be feasible for me to recompile whole tool-chain kit since, I do not have sources for the same.
   

Thanks & Regards,
Hiren


--- On Mon, 10/13/08, Nicholas Nethercote <nj...@cs...> wrote:

> From: Nicholas Nethercote <nj...@cs...>
> Subject: Re: [Valgrind-users] ppc e500 - declined to decode an AltiVec insn - vmhaddshs
> To: "Michael Poole" <md...@tr...>
> Cc: "Chris Packham" <jud...@gm...>, "Hiren Gajjar" <hir...@ya...>, val...@li...
> Date: Monday, October 13, 2008, 12:54 AM
> On Tue, 7 Oct 2008, Michael Poole wrote:
> 
> > 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.
> 
> Wow.  That is obnoxious.
> 
> N