Re: front end changes for altivec

[mike stump <mrs at windriver dot com>]

> Date: Tue, 27 Nov 2001 14:50:22 -0800
> From: Stan Shebs <shebs@apple.com>
> To: Richard Henderson <rth@redhat.com>

> You mean like how we don't have machine-dependent sizes for int
> and long int?

If in the end we have a portable thing that users can use in a fairly
simple and straight forward way, that allows them to switch from a mmx
machine to an sse machine, to an sse2 machine, to a ...  machine, we
win.  A good design is also forward compatible with strange hardware
that might come up in the future, or strange new operations...

On a good number of machines, almost all that matter, int is 32 bits,
long int is 32 bits.  I can't help but wonder if C would have been a
better standard, if they had just outright said, ints are 32 bits,
period.  It would have removed one major source of confusion and
increased (in a theoretical sense only) the portability of user code.

I can't help but think that code that does:

vector<int[4]> a, b;

int foo() { a += b; }

is intrinsically better than

vector<int> a, b;

int foo() { a += b; }

We can engineer gcc to have the first work on all machines, quickly on
some, `normal' speed on the rest.  C++ people, don't let the second
confuse you into thinking of std::vector, it is totally different.
Think gnu::gcc::vector.

In reading code like:

vector<int[32]> a, b;

int foo() { a += b; }

I can say, wow, someone has an arm core with a beefy vector unit
attached on an ASIC and I bet this puppy smokes.  I can also know that
I could compile it up as portable C code, and it would run on anything
GNU C supports, though, I might want a faster box in the end (bearing
in mind that sizeof(int)==4).