front end changes for altivec

[Aldy Hernandez]

On Tue, Nov 27, 2001 at 01:04:05AM +0000, Joseph S. Myers wrote:
> On Mon, 26 Nov 2001, Aldy Hernandez wrote:
> 
> > __vector must be first among type specifiers.  the specs are rather skekchy,
> 
> That's not consistent with how other type specifiers work.  It would make
> more sense for the list of possible type specifier combinations to include
> such things as "__vector signed int" and any permutation thereof.

sure

> > ok, but how would we differentiate between the diff vector sizes.
> > altivec has "vector int" being V4SI, but vector int could mean V2SI in
> > mmx.  suggestion welcome while i think through this.
> 
> 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

i don't link this idea.

> 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

i'm not sure i follow., can you give an example.

> "vector(4)".  Or add some other way of specifying a non-default vector
> size.

that could be better. 
> 
> > correct.  you can't convert between any of the vector types.  the following
> > just does a straight copy, no conversion (nop):
> > 
> >   vector short b;
> >   vector int a = (vector int) b;
> 
> What about other operations, e.g. arithmetic?

not allowed. or perhaps undefined


> > 	vector int foo = ((vector int)(1,2,3,4));
> > 
> > this kinda sucks all together because i don't think gcc has vector constants
> > at all, do we?  we could pass it as a BLKmode or as a struct right?
> 
> I think you should just use the C99 compound literal syntax here (with

yes, ideally.  but what do we do for the current specs which specifies
parentheses?

aldy