This is the mail archive of the
mailing list for the GCC project.
Re: front end changes for altivec
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: Aldy Hernandez <aldyh at cygnus dot com>
- Cc: Aldy Hernandez <aldyh at redhat dot com>, <gcc at gcc dot gnu dot org>
- Date: Tue, 27 Nov 2001 01:04:05 +0000 (GMT)
- Subject: Re: front end changes for altivec
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.
> 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
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
> 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?
> 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
braces, not parentheses). Presumably the ABI says how such arguments are
Joseph S. Myers