RE: Status of SSE support in current gcc mainline

[Daniel Berlin <dan at www dot cgsoftware dot com>]

On Fri, 23 Mar 2001 kumar@chaos.ph.utexas.edu wrote:

> > 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

Except you have missed that it also allows things like:

c = (vector int)((unsigned  int)(1, 2, 3, 4))
and other fun expressions that need to be built into your parser.
rather than
c = vector_set(1, 2, 3 ,4).