Re: Target-specific Front-Ends? (Was: front end changes for

[Mark Mitchell <mark at codesourcery dot com>]

--On Tuesday, November 27, 2001 02:53:26 PM -0800 Joe Buck 
<jbuck@synopsys.COM> wrote:

> Mark writes:
>> Concretely, the Altivec specification allows "vector" to be either a
>> macro, or a context-sensitive keyword.  The latter is a much better
>> choice, and it is the one we should adopt in GCC.  It will be far
>> less intrusive.
>
> Allowing "vector" to be a macro would be completely unacceptable, because
> people will mix C and C++ code.

The Altivec specification says that __vector is a keyword.  It says that
vector can be either a macro or a context-sensitive keyword.  If it
is a macro you are explicitly allowed to #undef it.

So, you can use __vector in C or C++, with any Altivec compiler.  If
you're using (Altivec) vector in C++ code, you're not writing
portable code, even across Altivec implementations.

I don't know how many Altivec code authors know this, but we would
certainly be within the letter of the law going this way, and it's
(relatively) easy to implement, and far less horrid than a
context-sensitive keyword.

>> Other things are more difficult.  Vector literals should just be
>> C99 compound literals, but I'm not sure whether we can get away
>> with changing that or not.
>
> A modest proposal:
>
> Consider a preprocessor that takes current Altivec C code and produces
> either standard or extended C code (GNU extensions).  If adopting the
> existing Altivec syntax is too painful, a second choice might be to figure
> out syntax choices that would make such a preprocessor very easy to write.
> Then we don't have to ask existing users to rewrite their code.

Yup, I thought about this too.  It's plausible, but a pretty substantial
effort, and not easy to do robustly with the tools we've got.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com