Re: Status of SSE support in current gcc mainline

[Daniel Berlin <dberlin at redhat dot com>]

"Dave Korn" <davek-ml@ntlworld.com> writes:

> 
>   Is that the same as the Altivec-enabled 2.95.2 available at
> http://www.altivec.org/ ?  I couldn't find anything obvious on that website
> that mentioned who was behind it.
> 
<swipe>
If I was the person who came up with those completely unneeded extra
keywords, fundamental datatypes, and extensions to C/C++
when intrinsics and a good  auto-parallelizing pass would do the same
(or at least, do something  without destroying all semblance of
portability), I wouldn't put my name on it either.

It's very confusing.
For instance, you can't use a vector of typedef'd types, only
of basic types, regardless if the typedef is a typedef of a basic type
or not.
IE
typedef unsigned short uint16;
vector uint16 data;
is not allowed
even though
vector unsigned short data;
is 

I mean, they added "bool" to C, even, just so they could have a vector
bool.

They specify the sizeof of their vector types to always be 16, and the
sizeof *pointers* to the vector types to be 16 as well.
Did I mention that the vector types are, in reality, a few different
sizes, and the pointers certainly aren't 16 bytes?
I guess 16 just seemed like a nice number.


I may seem to be being a little harsh, but it's not like they were the
first to ever have to design a programming interface to this stuff.

It looks like they implemented it first, and designed the programming
interface based on the implementation.

Why do you think you'll probably never see the altivec patches in FSF gcc,
at least in the form they take now?

</swipe>
There, that's my rant of the month
--Dan

>          DaveK
> 

-- 
I bought one of those little glass ball things with the snow in
it.  You know, you turn it upside down then you turn it back and
it starts to snow.  I bought one, except this has a snow plow
that does it in rows.