This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Status of SSE support in current gcc mainline


> The advantage motorola was trying to give you was the ability to perform
> normal arithmetic operations on vector types, without having to remember
> to use "vector_add(a,b)" or something of the sort (IE you could just do
> a+b).
> 
> This is the same thing Intel's C++ class gives you, except they don't
> screw the base language to do it. They use overloaded operators.
> 
> If you want to use the intrinsics, which are basically scheduled asms, you
> can. I was just trying to give a way to do what motorola was trying to do.
> 
> If you want to use C, you have to use the intrinsics, obviously.
> 
> But i don't think it's worth introducing completely new extensions that
> aren't exactly all that nice, just so you can type "a+b" rather than
> "vec_add(a,b)".
> 
> 
I am not sure what documentation you are looking at but the Motorola
Programming Interface Manual for Altivec does not describe anything to
the  effect you are describing.

check out:

http://www.altivec.org/tech_specifications/altivec_pim.pdf

The idea behind the altivec PIM is using intrinsics like c = vec_add(a,b);
Based on how 'a' and 'b' are typed the compiler should figure out which
altivec instruction this maps to.  For example:

  vector float a,b,c;

  c = vec_add(a,b); 

would map to the altivec instruction

vaddfp VD, VA, VB.  

The AltiVec PIM does NOT describe the ability to do operations like this:

  vector float a,b,c;

  c = a + b;

- kumar


ignorance is bliss.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]