This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: front end changes for altivec
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