This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Baby's First AldyVec/AltiVec patch



On 23 Dec, 2003, at 15.30, Gabriel Dos Reis wrote:


Ziemowit Laski <zlaski@apple.com> writes:

| On 23 Dec, 2003, at 15.06, Gabriel Dos Reis wrote:
| > The *syntax* is valid, but the semantic is fundamentally different.
| >
| > That is a red flag.
| >
| > (1) it uses the same syntax to mean something completely different,
| > and given that C and C++ grammars are not really context-free,
| > I think there is more to say that a bare "the syntax is already
| > valid".
| >
| > (2) for the semantics, you already have an existing standard syntax
| > for saying exactly the same thing.
|
| Unfortunately, the "existing" syntax (by which I'm assuming you mean
| AldyVec) is not standard, whereas the syntax I'm proposing (as imperfect
| as it may be) _is_. :-(


No, I think you misunderstood.

(type) {1, 2, 3, 4}

is a standard C99 syntax to designate a compond literal.  And if "type"
designates an  array then you get an array compound literal.  That is
standard.

I was referring to the AltiVec PIM standard. The C99 standard is necessarily
silent on vector initializers, since it is silent on the topic of vectors
themselves (which are _not_ arrays). :-)


Having said this, I don't really disagree with you that using C99-style
brace initializers would be nicer. But this is not the point; the existing
AltiVec standard (which AldyVec does not follow) and extensive industry
usage says otherwise. One simply can't rewrite the laws of gravity on-the-fly
like this, as much as one would want to...


Furthermore, there is a proposal  considered and being actively worked
on by the C++ committee to get generalized initializers and
user-defined literals into the language and that proposal,
unsurprisingly, suggests the existing C99 syntax.  A discussion in the
C++ evolution group at the last meeting has shown that there is a
significant portion of C/C++ community out there that expects that
syntax to mean exactly that.

[...]

| > I would strongly recommand against extension experiments along that
| > line in GCC.
|
| If this truly were an "experiment", I might be inclined to agree with
| you.
| Alas, the syntactic extensions we're discussing have existed in
| production
| compilers (including Apple's version of gcc) for at least 5 years.

Similarly, many problematic GNU extensions has been there in
production versions for long time before we kick them out.

Yes, we often make engineering decisions that we rue later. :-) C'est la vie...

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]