Re: front end changes for altivec

[Bernd Schmidt <bernds at redhat dot com>]

On 27 Nov 2001, Aldy Hernandez wrote:

> On Tue, 2001-11-27 at 09:50, Andreas Jaeger wrote:
> > Aldy Hernandez <aldyh@cygnus.com> writes:
> > 
> > >> The answer from some quarters might be "vector int<4>" or "vector<4> int",
> > >> but this adds complications to the C grammar I don't really want there
> > >> since > can be part of a constant expression (so if going that way then do
> > >> as many as possible of defining disambiguating rules by reference to
> > >> existing practice, proving the existence or nonexistence of ambiguous
> > >> cases, describing how the parsing should be implemented).  Or use
> > >> "vector(4)".  Or add some other way of specifying a non-default vector
> > >
> > > i've thought about this some more.
> > >
> > > do we really need to specify a vector size?  simd architectures
> > > generally have a specific vector size, 64bits for sse* and 128bits for
> > > altivec.  
> > 
> > SSE is 128 bits.
> 
> sorry, mmx then.
> 
> which complicates things further... with this mmx and sse and sse2, what
> would the default be for "vector int"?  mmx is 64bits (right?) and sse
> is 128bits, so when we talk of vector int, what are we talking about.

I think all these problems show clearly that the extension is poorly thought
out and should not be included in gcc.


Bernd