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 Dec 23, 2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:

> Ziemowit Laski <zlaski@apple.com> writes:

> | 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.

'cept it came in a bit too late to be used as a basis in the design of
the AltiVec extensions.  Those extensions already exist, and they are
implemented in a number of compilers.

If we want to exempt ourselves from adopting such an industry
standard, I'm fine with that, since the syntax extensions are not a
beautiful work of language design, indeed.

My point is just that they're already widely used, and just because a
later standard came up with an alternate syntax is no argument to
prevent us from adopting it late.

I.e., I'm not for the extensions, I just think you're choosing the
wrong argument.  My reasoning wouldn't take into account the fact that
the later standard introduced similar functionality with a different
(saner) syntax, but rather that the existing AltiVec standard
introduces ambiguous constructs that we'd rather not support,
suggesting people to adopt a C99-compatible syntax instead.

If the world bites, we're fine.  If not, well, there will be patches
available for those who really want the old syntax.  And if that is
not enough, I guess we'll eventually have to give up and accept
existing practice.  It wouldn't be the first time that we bend over to
support broken standards, and it certainly wouldn't be the last
either.

> Your proposal is trying to give a well-defined syntax with a
> standard semantic, a different semantic than what it means and what
> people would expect it to mean. 

Except (I think) it would be semantically ill-formed, even though it
would parse correctly.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer


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