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

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

[Aldy Hernandez]

On Tue, 2001-11-27 at 17:36, Andi Kleen wrote:
> Aldy Hernandez <aldyh@redhat.com> writes:
> > 
> > It would be really nice if you guys contributed your internal changes
> > on a more regular basis.  Stan tells me there lots of Darwin
> > optimizations in the backend that you guys haven't contributed.  It's
> > just easier to get a better overall picture if we're all looking at
> > the same code base.
> 
> Perhaps that's because all their patches get shot down in sometimes
> unfair endless unproductive discussions ? (just remembering the "\p..." thread 
> some time ago) 

hey, i have to go through that too, but it's what a) improves gcc b)
gets the patches in eventually.  sure i have to put in extra work to get
patches in, but at least they make it in and they don't become a
maintenance nightmare-- having 2 separate trees and all.

> 
> -Andi
-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

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

[Aldy Hernandez]

On Tue, 2001-11-27 at 17:36, Andi Kleen wrote:
> Aldy Hernandez <aldyh@redhat.com> writes:
> > 
> > It would be really nice if you guys contributed your internal changes
> > on a more regular basis.  Stan tells me there lots of Darwin
> > optimizations in the backend that you guys haven't contributed.  It's
> > just easier to get a better overall picture if we're all looking at
> > the same code base.
> 
> Perhaps that's because all their patches get shot down in sometimes
> unfair endless unproductive discussions ? (just remembering the "\p..." thread 
> some time ago) 

hey, i have to go through that too, but it's what a) improves gcc b)
gets the patches in eventually.  sure i have to put in extra work to get
patches in, but at least they make it in and they don't become a
maintenance nightmare-- having 2 separate trees and all.

> 
> -Andi
-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

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

[mike stump]

> To: Ira Ruben <ira@apple.com>
> CC: gcc@gcc.gnu.org
> From: Geoff Keating <geoffk@geoffk.org>
> Date: 27 Nov 2001 12:10:15 -0800

> It won't work.  There's little or nothing that can be done about that;
> it wouldn't work even if 'vector' was a keyword.

#include <vector>
#include <gosh_what_name_here.h>

using gnu::gcc::vector;

vector<int[4]> a, b;
std::vector<int> cxx_vec;

void foo() {
     a += b;
     cxx_vec.begin();
}

or

#include <vector>
#include <gosh_what_name_here.h>

using std;

gnu::gcc::vector<int[4]> a, b;
vector<int> cxx_vec;

void foo() {
     a += b;
     cxx_vec.begin();
}

A completely trivial problem.  :-)

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

[Aldy Hernandez]

>>>>> "mike" == mike stump <mrs@windriver.com> writes:

 > gnu::gcc::vector<int[4]> a, b;
 > vector<int> cxx_vec;

 > void foo() {
 >      a += b;
 >      cxx_vec.begin();
 > }

 > A completely trivial problem.  :-)


for the record, i'm not proposing a vector keyword-- but a __vector
keyword, to be implemented in a target independent manner.

I don't think there's any plausible way of implementing "vector" and
having it coexist with STL and a myraid of other things.  That much is
clear.

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

[Aldy Hernandez]

>>>>> "mike" == mike stump <mrs@windriver.com> writes:

 > gnu::gcc::vector<int[4]> a, b;
 > vector<int> cxx_vec;

 > void foo() {
 >      a += b;
 >      cxx_vec.begin();
 > }

 > A completely trivial problem.  :-)


for the record, i'm not proposing a vector keyword-- but a __vector
keyword, to be implemented in a target independent manner.

I don't think there's any plausible way of implementing "vector" and
having it coexist with STL and a myraid of other things.  That much is
clear.

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

[mike stump]

> To: Ira Ruben <ira@apple.com>
> CC: gcc@gcc.gnu.org
> From: Geoff Keating <geoffk@geoffk.org>
> Date: 27 Nov 2001 12:10:15 -0800

> It won't work.  There's little or nothing that can be done about that;
> it wouldn't work even if 'vector' was a keyword.

#include <vector>
#include <gosh_what_name_here.h>

using gnu::gcc::vector;

vector<int[4]> a, b;
std::vector<int> cxx_vec;

void foo() {
     a += b;
     cxx_vec.begin();
}

or

#include <vector>
#include <gosh_what_name_here.h>

using std;

gnu::gcc::vector<int[4]> a, b;
vector<int> cxx_vec;

void foo() {
     a += b;
     cxx_vec.begin();
}

A completely trivial problem.  :-)

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

[mike stump]

> Date: Mon, 26 Nov 2001 18:26:45 -0800
> From: Ziemowit Laski <zlaski@apple.com>

> But this brings up a more general question, one that I've been
> meaning to ask of the wider community for quite some time: Should we
> come up with a generalized architecture in GCC (for all front-ends)
> to enable front-end extensions:

For the purposes you want it for, I propose we put this off into the
future as far as we can, with a little luck, we never do it.

> AltiVec is merely one example of an idiosyncratic extension that
> exists on only a small fraction of targets that GCC supports.  It
> would be nice to only enable the extension for the targets that need
> it

What would be nice, is to come up with language independent, machine
independent semantics that are nice, and provide them to the
frontends, and encourage the front ends to allow/expose them to the
user, in a MI way, since they are after all, MI.  We then use the
existing standard practice, if well designed, and we like it, to form
the basis of some future addition to the C/C++ language standard.  I
mean, they have MUL-ADD defined in the C99 standard (see fma in the
library), they certainly can add vector stuff.

Imagine a valarray of floats specialization in the C++ library that
uses vector float[8] internally, and feeds the += member functions to
the vector float[8] += gcc backend support code.  Just use valarray in
the natural way, and presto, the code uses a dual pipelined float[4]
hardware vector unit.  All the transformations to accomplish this
would be trivial enough (certainly easier than trying to intuit vector
usage in normal code.

Compile on a platform that doesn't have such hardware, the compiler
generates 8 calls to float +, as normal.  Maybe we want to expose the
maximal useful vec size, MATH_VEC_MAX_SIZE...  We might need to expose
the existence of particular operations.  Maybe...

By offering a MI way to do this, users can write their code in a
fairly portable way, and gain the benefits of such a standard.

The failings of the backend now, are, if the insn isn't supported by
the CPU, it doesn't work and the backend doesn't actually have any
operations, just a few types.  The failings of C/C++ languages are, we
need a standardized header to get at the operations, with standardized
names (not __builtin_addv4si), we might need a better syntax.  We need
to document all of the operations, and all operations always have to
work.  And we need to use these features in valarray.  We need to push
the standard out to the real folks that use these types of units, and
refine what we have to match what they need.

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

[mike stump]

> Date: Mon, 26 Nov 2001 18:26:45 -0800
> From: Ziemowit Laski <zlaski@apple.com>

> But this brings up a more general question, one that I've been
> meaning to ask of the wider community for quite some time: Should we
> come up with a generalized architecture in GCC (for all front-ends)
> to enable front-end extensions:

For the purposes you want it for, I propose we put this off into the
future as far as we can, with a little luck, we never do it.

> AltiVec is merely one example of an idiosyncratic extension that
> exists on only a small fraction of targets that GCC supports.  It
> would be nice to only enable the extension for the targets that need
> it

What would be nice, is to come up with language independent, machine
independent semantics that are nice, and provide them to the
frontends, and encourage the front ends to allow/expose them to the
user, in a MI way, since they are after all, MI.  We then use the
existing standard practice, if well designed, and we like it, to form
the basis of some future addition to the C/C++ language standard.  I
mean, they have MUL-ADD defined in the C99 standard (see fma in the
library), they certainly can add vector stuff.

Imagine a valarray of floats specialization in the C++ library that
uses vector float[8] internally, and feeds the += member functions to
the vector float[8] += gcc backend support code.  Just use valarray in
the natural way, and presto, the code uses a dual pipelined float[4]
hardware vector unit.  All the transformations to accomplish this
would be trivial enough (certainly easier than trying to intuit vector
usage in normal code.

Compile on a platform that doesn't have such hardware, the compiler
generates 8 calls to float +, as normal.  Maybe we want to expose the
maximal useful vec size, MATH_VEC_MAX_SIZE...  We might need to expose
the existence of particular operations.  Maybe...

By offering a MI way to do this, users can write their code in a
fairly portable way, and gain the benefits of such a standard.

The failings of the backend now, are, if the insn isn't supported by
the CPU, it doesn't work and the backend doesn't actually have any
operations, just a few types.  The failings of C/C++ languages are, we
need a standardized header to get at the operations, with standardized
names (not __builtin_addv4si), we might need a better syntax.  We need
to document all of the operations, and all operations always have to
work.  And we need to use these features in valarray.  We need to push
the standard out to the real folks that use these types of units, and
refine what we have to match what they need.

Re: front end changes for altivec

[Joseph S. Myers]

On 26 Nov 2001, Aldy Hernandez wrote:

> the altivec specs require changes to the gcc front end.  this has been
> brought up before but no one has really commented.  now before everyone
> start raising shields and going "yuck, no way", hear me out.

You have of course read the previous thread on "Vector Extensions in GCC"  
from July.

>     __vector keyword:
>     
>     	__vector int	=> mode(V4SI)
>     	__vector char	=> mode(V16QI)
>     	etc etc

Precise rules?  Is __vector a type specifier that can be added to the
various lists of keyword type specifiers that can be used?  Which of the
type specifiers listed in C99 6.7.2#2 can it be used with?  I take it it
can't be used with typedefs, structs or unions.  Can it be used with
enums?  Why those particular sizes of vectors rather than others?  Will
__vector on its own imply __vector int?

Given proper answers, thorough documentation and testcases and a design of
an architecture-independent __vector keyword that allows for the variety
of vector types on different architectures, this is comparatively harmless
- as long as there are no implicit conversions between these types and any
other type in either direction and no operations can be applied to these
types other than passing to and returning from functions, and any explicit
conversions available are properly documented and justified.

>     vector constant initializers:
>     
>     	__vector int foo = (5, 8, 3, 2);
>     
>     (yes, those are parentheses, not curlys :-()

Obviously a bad idea - (5, 8, 3, 2) has a defined meaning that does not
depend on the context here.  This is worse than was suggested in July
(which was (vector float) (1.0, 2.0, 3.0, 4.0)) though that still ought to
be a compound literal instead.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

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

[Ziemowit Laski]

On Monday, November 26, 2001, at 03:45 , Joseph S. Myers wrote:

> On 26 Nov 2001, Aldy Hernandez wrote:
>
>> the altivec specs require changes to the gcc front end.  this has been
>> brought up before but no one has really commented.  now before everyone
>> start raising shields and going "yuck, no way", hear me out.

Unfortunately, AltiVec extensions are (syntactically) quite yucky.  
Legacy
Motorola/Apple/IBM code is likely to rely not only on '__vector' and 
'__pixel'
and 'bool' (in its non-C++ sense!) but also 'vector', 'pixel' and even 
'__bool'!
If I had my druthers, I'd just stick to the '__attribute__(...)' 
notation, but
obviously I don't have my druthers. :(  At any rate, AltiVec syntax is 
not
easy to "intellectually reconcile" with any of the underlying 
languages.  (And
yes, we do have it in our Apple gcc3 tree...)

But this brings up a more general question, one that I've been meaning to
ask of the wider community for quite some time: Should we come up with a
generalized architecture in GCC (for all front-ends) to enable front-end
extensions:
   1) only for specific platforms (e.g., Altivec for PPC targets, 
'dllexport'
      for Windows, etc.); and/or
   2) only when explicitly specified via the configure script (e.g.,
      '--enable-altivec-keywords', '--enable-pascal-strings')

AltiVec is merely one example of an idiosyncratic extension that exists 
on
only a small fraction of targets that GCC supports.  It would be nice to
only enable the extension for the targets that need it, analogously to
how back-end bits are pulled in from gcc/config/....  Naturally, it
would also be up to the maintainer(s) of a particular target to ensure
that the front-end extensions continue to work with the main (generic)
front-end.

Anyway, this is just a thought.  I'd be curious as to what the rest of 
you
think about this.

--Zem
--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085

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

[Aldy Hernandez]

> Unfortunately, AltiVec extensions are (syntactically) quite yucky.  
> Legacy
> Motorola/Apple/IBM code is likely to rely not only on '__vector' and 
> '__pixel'

very yucky and i'm getting the feeling it's never going to be approved
as is-- as the motorola specs stand.

> But this brings up a more general question, one that I've been meaning to
> ask of the wider community for quite some time: Should we come up with a
> generalized architecture in GCC (for all front-ends) to enable front-end

it should only be enabled with a flag.

aldy

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

[Aldy Hernandez]

> Unfortunately, AltiVec extensions are (syntactically) quite yucky.  
> Legacy
> Motorola/Apple/IBM code is likely to rely not only on '__vector' and 
> '__pixel'

very yucky and i'm getting the feeling it's never going to be approved
as is-- as the motorola specs stand.

> But this brings up a more general question, one that I've been meaning to
> ask of the wider community for quite some time: Should we come up with a
> generalized architecture in GCC (for all front-ends) to enable front-end

it should only be enabled with a flag.

aldy

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

[Stan Shebs]

Ziemowit Laski wrote:
> 
> But this brings up a more general question, one that I've been meaning to
> ask of the wider community for quite some time: Should we come up with a
> generalized architecture in GCC (for all front-ends) to enable front-end
> extensions:
>    1) only for specific platforms (e.g., Altivec for PPC targets,
> 'dllexport'
>       for Windows, etc.); and/or
>    2) only when explicitly specified via the configure script (e.g.,
>       '--enable-altivec-keywords', '--enable-pascal-strings')

When you put it that way, my general reaction is to say "bleah". :-)

GCC philosophy has never been to implement every feature ever seen
in somebody else's compiler, but instead to have a single compiler
that behaves consistently across a range of architectures and
operating systems.  There are frontend extension mechanisms, such
as pragmas and attributes for C dialects for instance, as well as
builtin functions, so there is plenty to work with already.  It
may be that these are inadequate, but the case would have to
be pretty compelling on technical grounds.

For instance, in the case of AltiVec extensions, the effect of
vector/pixel keywords can be almost entirely achieved with mode
attributes, the overloaded builtins could be handled by adding
a general concept of overloaded builtins, leaving only the vector
constant syntax as an oddball.  From what I know of the AltiVec-
using population, the total aggregate effort of changing the
syntax of all the vector constants in source code might add up
to as much as one day - less than the effort needed to get the
extension working in GCC.  So should we implement the extension
and support it forever, or get users to spend a few minutes to
change their sources?

The moral of the story with respect to AltiVec is that GNU people
should try to be more involved when new technologies are being
introduced.  As far as I know (I admit to being out of the loop
myself), the AltiVec programming model was designed by a group
working on various proprietary compilers, and the question of GCC
support didn't come up until later.  There were some real boners,
such as the context sensitivity of the vector keyword, that I think
could have been avoided if some GCC folks had participated.

It's easy to say "oh, I can't do anything without having a signed
contract first" or "why should I care about PowerPC/x86/ARM/etc",
but in cases like these some upfront interest and nosiness will
pay off in the long run; we can then spend our development time on
improvements that benefit everybody, rather than tricky hacks to
support another limited-interest target-specific extension.

Stan

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

[Ira Ruben]

At 10:22 PM -0800 11/26/01, Stan Shebs wrote:

From what I know of the AltiVec-
>using population, the total aggregate effort of changing the
>syntax of all the vector constants in source code might add up
>to as much as one day - less than the effort needed to get the
>extension working in GCC.  So should we implement the extension
>and support it forever, or get users to spend a few minutes to
>change their sources?

I think there would be a lot of resistance to go back and change existing code.  Also you need to consider the impact this would have on MetroWerks users when porting to gcc, not to mention the requisite change for the MW compiler itself (of course they could support both forms).



>There were some real boners,
>such as the context sensitivity of the vector keyword, that I think
>could have been avoided if some GCC folks had participated.

At the time the AltiVec language model was being designed gcc was never in the picture -- period!  The only "players" were MrC[pp] and Moto's Mcc (not even MW).  I'm not sure what prompted Moto to try to later retrofit the design into gcc.  And I don't consider the use of "vector" as a context-sensitive keyword a "real boner".  THAT WAS MY DECISION/DESIGN!  For MrC[pp] is was easy to do.  And it was based on feedback from our internal (Apple) AltiVec users (the *only* users at that time other than Moto).  They didn't want to write __vector and they certainly couldn't tolerate "vector" being a macro that expanded to __vector (which Moto was proposing).  And "vector" couldn't be treated as an unconditional reserved word either.

Ira

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

[Aldy Hernandez]

    couldn't tolerate "vector" being a macro that expanded to __vector

uhhh, that's exactly what i'm going to do for gcc.  it's either that or
keep a separate set of patches.


-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

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

[Ira Ruben]

At 8:47 AM -0600 11/27/01, Aldy Hernandez wrote:

>     couldn't tolerate "vector" being a macro that expanded to __vector
>
>uhhh, that's exactly what i'm going to do for gcc.  it's either that or
>keep a separate set of patches.

And if someone is trying to use stl's class vector then what happens?

Ira

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

[Geoff Keating]

Ira Ruben <ira@apple.com> writes:

> At 8:47 AM -0600 11/27/01, Aldy Hernandez wrote:
> 
> >     couldn't tolerate "vector" being a macro that expanded to __vector
> >
> >uhhh, that's exactly what i'm going to do for gcc.  it's either that or
> >keep a separate set of patches.
> 
> And if someone is trying to use stl's class vector then what happens?

It won't work.  There's little or nothing that can be done about that;
it wouldn't work even if 'vector' was a keyword.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

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

[Ira Ruben]

At 12:10 PM -0800 11/27/01, Geoff Keating wrote:

>Ira Ruben <ira@apple.com> writes:
>
>>  At 8:47 AM -0600 11/27/01, Aldy Hernandez wrote:
>>
>>  >     couldn't tolerate "vector" being a macro that expanded to __vector
>>  >
>>  >uhhh, that's exactly what i'm going to do for gcc.  it's either that or
>>  >keep a separate set of patches.
>>
>>  And if someone is trying to use stl's class vector then what happens?
>
>It won't work.  There's little or nothing that can be done about that;
>it wouldn't work even if 'vector' was a keyword.

That was a rhetorical question!

It was precisely that reason why 'vector' was made a context 
sensitive type id and not a unconditional keyword.  Doing it that way 
allowed it to be used in that type context while still allowing class 
vector to work or the use of 'vector' in any other way.

Ira

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

[Phil Edwards]

On Tue, Nov 27, 2001 at 12:48:00PM -0800, Ira Ruben wrote:
> It was precisely that reason why 'vector' was made a context 
> sensitive type id and not a unconditional keyword.  Doing it that way 
> allowed it to be used in that type context while still allowing class 
> vector to work or the use of 'vector' in any other way.

Has anybody tried

    #include <vector>
    std::vector<vector int>  foo;

yet?  Or with the backwards-compat header

    #include <vector.h>
    vector<vector int>  foo;

I could see the first possibly working, but the second is almost certain
to break.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

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

[Phil Edwards]

On Tue, Nov 27, 2001 at 12:48:00PM -0800, Ira Ruben wrote:
> It was precisely that reason why 'vector' was made a context 
> sensitive type id and not a unconditional keyword.  Doing it that way 
> allowed it to be used in that type context while still allowing class 
> vector to work or the use of 'vector' in any other way.

Has anybody tried

    #include <vector>
    std::vector<vector int>  foo;

yet?  Or with the backwards-compat header

    #include <vector.h>
    vector<vector int>  foo;

I could see the first possibly working, but the second is almost certain
to break.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

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

[Ira Ruben]

At 12:10 PM -0800 11/27/01, Geoff Keating wrote:

>Ira Ruben <ira@apple.com> writes:
>
>>  At 8:47 AM -0600 11/27/01, Aldy Hernandez wrote:
>>
>>  >     couldn't tolerate "vector" being a macro that expanded to __vector
>>  >
>>  >uhhh, that's exactly what i'm going to do for gcc.  it's either that or
>>  >keep a separate set of patches.
>>
>>  And if someone is trying to use stl's class vector then what happens?
>
>It won't work.  There's little or nothing that can be done about that;
>it wouldn't work even if 'vector' was a keyword.

That was a rhetorical question!

It was precisely that reason why 'vector' was made a context 
sensitive type id and not a unconditional keyword.  Doing it that way 
allowed it to be used in that type context while still allowing class 
vector to work or the use of 'vector' in any other way.

Ira

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

[Geoff Keating]

Ira Ruben <ira@apple.com> writes:

> At 8:47 AM -0600 11/27/01, Aldy Hernandez wrote:
> 
> >     couldn't tolerate "vector" being a macro that expanded to __vector
> >
> >uhhh, that's exactly what i'm going to do for gcc.  it's either that or
> >keep a separate set of patches.
> 
> And if someone is trying to use stl's class vector then what happens?

It won't work.  There's little or nothing that can be done about that;
it wouldn't work even if 'vector' was a keyword.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

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

[Aldy Hernandez]

On Tue, 2001-11-27 at 12:54, Ira Ruben wrote:
> At 8:47 AM -0600 11/27/01, Aldy Hernandez wrote:
> 
> >     couldn't tolerate "vector" being a macro that expanded to __vector
> >
> >uhhh, that's exactly what i'm going to do for gcc.  it's either that or
> >keep a separate set of patches.
> 
> And if someone is trying to use stl's class vector then what happens?

if you include <altivec.h> then you get the vector macro, and the
overloaded functions.  if you don't, you're safe.

> 
> Ira
-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

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

[Aldy Hernandez]

On Tue, 2001-11-27 at 12:54, Ira Ruben wrote:
> At 8:47 AM -0600 11/27/01, Aldy Hernandez wrote:
> 
> >     couldn't tolerate "vector" being a macro that expanded to __vector
> >
> >uhhh, that's exactly what i'm going to do for gcc.  it's either that or
> >keep a separate set of patches.
> 
> And if someone is trying to use stl's class vector then what happens?

if you include <altivec.h> then you get the vector macro, and the
overloaded functions.  if you don't, you're safe.

> 
> Ira
-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

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

[Ziemowit Laski]

On Tuesday, November 27, 2001, at 06:47 , Aldy Hernandez wrote:

>
>     couldn't tolerate "vector" being a macro that expanded to __vector
>
> uhhh, that's exactly what i'm going to do for gcc.  it's either that or
> keep a separate set of patches.

We at Apple do the latter. :(
--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085

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

[Aldy Hernandez]

On Tue, 2001-11-27 at 14:41, Ziemowit Laski wrote:
> 
> On Tuesday, November 27, 2001, at 06:47 , Aldy Hernandez wrote:
> 
> >
> >     couldn't tolerate "vector" being a macro that expanded to __vector
> >
> > uhhh, that's exactly what i'm going to do for gcc.  it's either that or
> > keep a separate set of patches.
> 
> We at Apple do the latter. :(

you mean implement a "vector" keyword?  hmm, can't do c++ STL stuff
then.

> --------------------------------------------------------------
> Ziemowit Laski                   Apple Computer, Inc.
> zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
> +1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085
-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

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

[Ziemowit Laski]

On Tuesday, November 27, 2001, at 01:15 , Aldy Hernandez wrote:
>> We at Apple do the latter. :(
>
> you mean implement a "vector" keyword?  hmm, can't do c++ STL stuff
> then.

Sure can -- it is context-sensitive, as Ira pointed out.
>
--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085

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

[Ziemowit Laski]

On Tuesday, November 27, 2001, at 01:15 , Aldy Hernandez wrote:
>> We at Apple do the latter. :(
>
> you mean implement a "vector" keyword?  hmm, can't do c++ STL stuff
> then.

Sure can -- it is context-sensitive, as Ira pointed out.
>
--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085

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

[Aldy Hernandez]

On Tue, 2001-11-27 at 14:41, Ziemowit Laski wrote:
> 
> On Tuesday, November 27, 2001, at 06:47 , Aldy Hernandez wrote:
> 
> >
> >     couldn't tolerate "vector" being a macro that expanded to __vector
> >
> > uhhh, that's exactly what i'm going to do for gcc.  it's either that or
> > keep a separate set of patches.
> 
> We at Apple do the latter. :(

you mean implement a "vector" keyword?  hmm, can't do c++ STL stuff
then.

> --------------------------------------------------------------
> Ziemowit Laski                   Apple Computer, Inc.
> zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
> +1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085
-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

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

[Ziemowit Laski]

On Tuesday, November 27, 2001, at 06:47 , Aldy Hernandez wrote:

>
>     couldn't tolerate "vector" being a macro that expanded to __vector
>
> uhhh, that's exactly what i'm going to do for gcc.  it's either that or
> keep a separate set of patches.

We at Apple do the latter. :(
--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085

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

[Aldy Hernandez]

    couldn't tolerate "vector" being a macro that expanded to __vector

uhhh, that's exactly what i'm going to do for gcc.  it's either that or
keep a separate set of patches.


-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

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

[Per Bothner]

Ira Ruben wrote:

>I think there would be a lot of resistance to go back and change existing code.
>
Not as great as the resistance to adding target-specific kludges
to the gcc front-end.

    --Per Bothner

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

[Per Bothner]

Ira Ruben wrote:

>I think there would be a lot of resistance to go back and change existing code.
>
Not as great as the resistance to adding target-specific kludges
to the gcc front-end.

    --Per Bothner

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

[Stan Shebs]

Ira Ruben wrote:
> 
> >There were some real boners,
> >such as the context sensitivity of the vector keyword, that I think
> >could have been avoided if some GCC folks had participated.
> 
> At the time the AltiVec language model was being designed gcc was
> never in the picture -- period!  The only "players" were MrC[pp] and
> Moto's Mcc (not even MW).  I'm not sure what prompted Moto to try to
> later retrofit the design into gcc.

Easy - Motorola wasn't going to be able to sell G4s to either
Linux or embedded users (VxWorks etc) without having AltiVec
support in GCC.  It speaks volumes that nobody at Motorola seemed
to be aware that GCC was Wind River's standard compiler, and
that it thus might be a good idea to talk to GCC people about the
proposed extension.

> And I don't consider the use of
> "vector" as a context-sensitive keyword a "real boner".  THAT WAS MY
> DECISION/DESIGN!

I wasn't going to mention your name, but if you want to take
credit I can't stop you... :-)

> For MrC[pp] is was easy to do.  And it was based on
> feedback from our internal (Apple) AltiVec users (the *only* users at
> that time other than Moto).  They didn't want to write __vector and
> they certainly couldn't tolerate "vector" being a macro that expanded
> to __vector (which Moto was proposing).  And "vector" couldn't be
> treated as an unconditional reserved word either.

Nevertheless, I still think it was a mistake.  When it comes to
messing with the language, we often need to say "no" to users, who
typically don't understand the consequences of tinkering with language
syntax and semantics - indeed, they're paying us to be the experts.
While it may have been easy to do in MrC, did anybody consider that
the extension was going to affect every other PowerPC compiler in
the world?  Ironically, this extension makes our internal version of
GCC more complicated and time-consuming to merge with FSF sources, so
our imports take longer and have more problems, which means that your
own daily work today has been made more difficult by the expedient
choice of several years ago.

Stan

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

[Ira Ruben]

At 9:47 AM -0800 11/27/01, Stan Shebs wrote:

>Easy - Motorola wasn't going to be able to sell G4s to either
>Linux or embedded users (VxWorks etc) without having AltiVec
>support in GCC.  It speaks volumes that nobody at Motorola seemed
>to be aware that GCC was Wind River's standard compiler, and
>that it thus might be a good idea to talk to GCC people about the
>proposed extension.
>
>...
>
>Nevertheless, I still think it was a mistake.  When it comes to
>messing with the language, we often need to say "no" to users, who
>typically don't understand the consequences of tinkering with language
>syntax and semantics - indeed, they're paying us to be the experts.
>While it may have been easy to do in MrC, did anybody consider that
>the extension was going to affect every other PowerPC compiler in
>the world?  Ironically, this extension makes our internal version of
>GCC more complicated and time-consuming to merge with FSF sources, so
>our imports take longer and have more problems, which means that your
>own daily work today has been made more difficult by the expedient
>choice of several years ago.

I'm not going to get into a debate with you about design decisions of 
the past when you weren't there and don't know the context in which 
those were made.  It may be your opinion about how "hard" it is to 
support "vector" this way.  I do not agree.  If it was so easy for 
MrC[pp] and I assume Mcc and MW I do not see a problem with gcc.

Ira

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

[Per Bothner]

Ira Ruben wrote:

> At 9:47 AM -0800 11/27/01, Stan Shebs wrote:
>
> I'm not going to get into a debate with you about design decisions of 
> the past when you weren't there and don't know the context in which 
> those were made.  It may be your opinion about how "hard" it is to 
> support "vector" this way. 

You're missing the point, which is not how easy or hard it is to implement
the feature.  The hard part is coming up with an acceptable, well-defined,
documented, portable feature that makes sense in the context of gcc,
that can be maintained, and that you can get the gcc maintainers to 
agree to.

> I do not agree.  If it was so easy for MrC[pp] and I assume Mcc and MW 
> I do not see a problem with gcc.

Perhaps because we here have a longer-term perspective, or because we 
have different
priorities.  We support vastly more targets than they do.

    --Per Bothner

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

[Daniel Berlin]

On Tue, 27 Nov 2001, Per Bothner wrote:

> Ira Ruben wrote:
>
> > At 9:47 AM -0800 11/27/01, Stan Shebs wrote:
> >
> > I'm not going to get into a debate with you about design decisions of
> > the past when you weren't there and don't know the context in which
> > those were made.  It may be your opinion about how "hard" it is to
> > support "vector" this way.
>
> You're missing the point, which is not how easy or hard it is to implement
> the feature.  The hard part is coming up with an acceptable, well-defined,
> documented, portable feature that makes sense in the context of gcc,
> that can be maintained, and that you can get the gcc maintainers to
> agree to.
>
> > I do not agree.  If it was so easy for MrC[pp] and I assume Mcc and MW
> > I do not see a problem with gcc.
>
> Perhaps because we here have a longer-term perspective, or because we
> have different
> priorities.  We support vastly more targets than they do.
>
And more to the point, we already have targets with different vector
sizes.
It's not just a theoretical possibility.
It already exists.

>     --Per Bothner
>
>

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

[Daniel Berlin]

On Tue, 27 Nov 2001, Per Bothner wrote:

> Ira Ruben wrote:
>
> > At 9:47 AM -0800 11/27/01, Stan Shebs wrote:
> >
> > I'm not going to get into a debate with you about design decisions of
> > the past when you weren't there and don't know the context in which
> > those were made.  It may be your opinion about how "hard" it is to
> > support "vector" this way.
>
> You're missing the point, which is not how easy or hard it is to implement
> the feature.  The hard part is coming up with an acceptable, well-defined,
> documented, portable feature that makes sense in the context of gcc,
> that can be maintained, and that you can get the gcc maintainers to
> agree to.
>
> > I do not agree.  If it was so easy for MrC[pp] and I assume Mcc and MW
> > I do not see a problem with gcc.
>
> Perhaps because we here have a longer-term perspective, or because we
> have different
> priorities.  We support vastly more targets than they do.
>
And more to the point, we already have targets with different vector
sizes.
It's not just a theoretical possibility.
It already exists.

>     --Per Bothner
>
>

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

[Ziemowit Laski]

On Tuesday, November 27, 2001, at 11:16 , Per Bothner wrote:

> Ira Ruben wrote:
>
>> At 9:47 AM -0800 11/27/01, Stan Shebs wrote:
>>
>> I'm not going to get into a debate with you about design decisions of 
>> the past when you weren't there and don't know the context in which 
>> those were made.  It may be your opinion about how "hard" it is to 
>> support "vector" this way.
>
> You're missing the point, which is not how easy or hard it is to 
> implement
> the feature.  The hard part is coming up with an acceptable, 
> well-defined,
> documented, portable feature that makes sense in the context of gcc,
> that can be maintained, and that you can get the gcc maintainers to 
> agree to.

No! :) The features were are talking about here are TARGET-SPECIFIC and 
hence need not
be any more portable, well-defined, documented, etc., than the machine 
descriptions
for those targets.  The people concerned with AltiVec keywords will be, 
for the most
part, the same group that is concerned with the contents of 
gcc/config/rs6000/rs6000.md.

The idea here is to find a way in which people NOT concerned with 
AltiVec do not ever have
to lay their eyes on an AltiVec keyword (just as they don't have to look 
at rs6000.md).
This is the essence of my proposal.

--Zem
--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085

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

[Per Bothner]

Ziemowit Laski wrote:

> No! :) The features were are talking about here are TARGET-SPECIFIC 
> and hence need not
> be any more portable, well-defined, documented, etc., than the machine 
> descriptions
> for those targets. 

Why would we want to put into our compiler a TARGET-SPECIFIC syntactic
extension to handle the rather generic concept of a fixed-size vector? 
 And why
would we want to add a configure mechanism to do that?

Let me answer for you:  We don't.

What we want is a *generic* machine-independent syntax, with optional
target-specfic optimization patterns.  If you don't want to or can't do 
that,
no problem.  Feel free to maintain your own tree with whatever extensions
you want - it's Free Software.  But I will vote against any suggestion to
allow such code to be checkled into the CVS mainline.

    --Per Bothner

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

[Ziemowit Laski]

On Tuesday, November 27, 2001, at 05:36 , Per Bothner wrote:

> Ziemowit Laski wrote:
>
>> No! :) The features were are talking about here are TARGET-SPECIFIC 
>> and hence need not
>> be any more portable, well-defined, documented, etc., than the machine 
>> descriptions
>> for those targets.
>
> Why would we want to put into our compiler a TARGET-SPECIFIC syntactic
> extension to handle the rather generic concept of a fixed-size vector? 
> And why
> would we want to add a configure mechanism to do that?

Two words: LEGACY CODE.

>
> Let me answer for you:  We don't.
>
> What we want is a *generic* machine-independent syntax, with optional

If we were designing AltiVec syntax today, I would absolutely agree.  
But we're
not.  We have a bunch of code, supported by a bunch of compilers 
(including
Apple's gcc-2.95.2).  Yes, it's ugly, but it's out there in the real 
world.

> no problem.  Feel free to maintain your own tree with whatever 
> extensions
> you want - it's Free Software.  But I will vote against any suggestion 
> to

Well, we do have a local tree, and it is a royal pain to maintain in sync
with the FSF, as Stan can attest. :)  In making my proposal, I assumed
(perhaps wrongly) that a lot of other organizations are in the same 
boat --
i.e., they have local modifications that they wouldn't mind putting into
the FSF, but can't because GCC is not sufficiently modular (at least not
for the front-end things) and the local things can't be kept sufficiently
target-specific (hence interfering with the mainline).

--Zem
--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085

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

[Per Bothner]

Ziemowit Laski wrote:

>
> On Tuesday, November 27, 2001, at 05:36 , Per Bothner wrote:
>
>> Why would we want to put into our compiler a TARGET-SPECIFIC syntactic
>> extension to handle the rather generic concept of a fixed-size 
>> vector? And why
>> would we want to add a configure mechanism to do that?
>
> Two words: LEGACY CODE.

I know of no GNU or otherwise Free or open-source software that uses
these extensions.  So the problem of legacy code is not a GNU problem.
Of course we want gcc to be generally useful, but it cannot be all things
to all people.

People who have code that uses these extensions can use a legacy compiler.
Or they can pay somebody (Apple or Red Hat, for example) to maintain a
compiler that supports the legacy code.

Their legacy code is not our problem - but it will be our problem if we 
accept
a kludgy extension into our sources.

> Well, we do have a local tree, and it is a royal pain to maintain in sync
> with the FSF, as Stan can attest. :)  In making my proposal, I assumed
> (perhaps wrongly) that a lot of other organizations are in the same 
> boat --
> i.e., they have local modifications that they wouldn't mind putting into
> the FSF

I'm sure a lot of companies are in the same boat.  That is their problem.
In principle we encourage them to merge in local modifications *if*
they are clean and generally useful.  Even more, we encourage people
to think about merging and design and discussing features with the gcc
maintainers *before* they start implementing.

    --Per Bothner

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

[Per Bothner]

Ziemowit Laski wrote:

>
> On Tuesday, November 27, 2001, at 05:36 , Per Bothner wrote:
>
>> Why would we want to put into our compiler a TARGET-SPECIFIC syntactic
>> extension to handle the rather generic concept of a fixed-size 
>> vector? And why
>> would we want to add a configure mechanism to do that?
>
> Two words: LEGACY CODE.

I know of no GNU or otherwise Free or open-source software that uses
these extensions.  So the problem of legacy code is not a GNU problem.
Of course we want gcc to be generally useful, but it cannot be all things
to all people.

People who have code that uses these extensions can use a legacy compiler.
Or they can pay somebody (Apple or Red Hat, for example) to maintain a
compiler that supports the legacy code.

Their legacy code is not our problem - but it will be our problem if we 
accept
a kludgy extension into our sources.

> Well, we do have a local tree, and it is a royal pain to maintain in sync
> with the FSF, as Stan can attest. :)  In making my proposal, I assumed
> (perhaps wrongly) that a lot of other organizations are in the same 
> boat --
> i.e., they have local modifications that they wouldn't mind putting into
> the FSF

I'm sure a lot of companies are in the same boat.  That is their problem.
In principle we encourage them to merge in local modifications *if*
they are clean and generally useful.  Even more, we encourage people
to think about merging and design and discussing features with the gcc
maintainers *before* they start implementing.

    --Per Bothner

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

[Stan Shebs]

Ziemowit Laski wrote:
> 
> Well, we do have a local tree, and it is a royal pain to maintain in sync
> with the FSF, as Stan can attest. :)

Unless Red Hat has significantly reduced their divergence recently,
Apple's local changes are probably still smaller than Red Hat's.
Our FSF import typically takes half a day, most of it spent waiting
for builds or cvs ops.

> In making my proposal, I assumed
> (perhaps wrongly) that a lot of other organizations are in the same
> boat --
> i.e., they have local modifications that they wouldn't mind putting into
> the FSF, but can't because GCC is not sufficiently modular (at least not
> for the front-end things) and the local things can't be kept sufficiently
> target-specific (hence interfering with the mainline).

The truth is that there aren't very many organizations who use
GCC on the same scale that Apple does.  None of the other big
computer vendors (Sun, HP, Compaq, etc) have adopted GCC as their
main or only compiler, and embedded system companies (with the
notable exception of Wind River) tend to use either an FSF or
Red Hat release as-is.

However, your proposal is still worth thought, because I believe
that the adoption of GCC by other system vendors is just a matter
of time, and they are going to face the same questions, whether
to adapt GCC to the environment or to adapt the environment to GCC.
The easy way out will always be to turn inwards and avoid working
with the community of GCC developers, but that's a sterile outcome
that we should all try to prevent.

Stan

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

[Stan Shebs]

Ziemowit Laski wrote:
> 
> Well, we do have a local tree, and it is a royal pain to maintain in sync
> with the FSF, as Stan can attest. :)

Unless Red Hat has significantly reduced their divergence recently,
Apple's local changes are probably still smaller than Red Hat's.
Our FSF import typically takes half a day, most of it spent waiting
for builds or cvs ops.

> In making my proposal, I assumed
> (perhaps wrongly) that a lot of other organizations are in the same
> boat --
> i.e., they have local modifications that they wouldn't mind putting into
> the FSF, but can't because GCC is not sufficiently modular (at least not
> for the front-end things) and the local things can't be kept sufficiently
> target-specific (hence interfering with the mainline).

The truth is that there aren't very many organizations who use
GCC on the same scale that Apple does.  None of the other big
computer vendors (Sun, HP, Compaq, etc) have adopted GCC as their
main or only compiler, and embedded system companies (with the
notable exception of Wind River) tend to use either an FSF or
Red Hat release as-is.

However, your proposal is still worth thought, because I believe
that the adoption of GCC by other system vendors is just a matter
of time, and they are going to face the same questions, whether
to adapt GCC to the environment or to adapt the environment to GCC.
The easy way out will always be to turn inwards and avoid working
with the community of GCC developers, but that's a sterile outcome
that we should all try to prevent.

Stan

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

[Ziemowit Laski]

On Tuesday, November 27, 2001, at 05:36 , Per Bothner wrote:

> Ziemowit Laski wrote:
>
>> No! :) The features were are talking about here are TARGET-SPECIFIC 
>> and hence need not
>> be any more portable, well-defined, documented, etc., than the machine 
>> descriptions
>> for those targets.
>
> Why would we want to put into our compiler a TARGET-SPECIFIC syntactic
> extension to handle the rather generic concept of a fixed-size vector? 
> And why
> would we want to add a configure mechanism to do that?

Two words: LEGACY CODE.

>
> Let me answer for you:  We don't.
>
> What we want is a *generic* machine-independent syntax, with optional

If we were designing AltiVec syntax today, I would absolutely agree.  
But we're
not.  We have a bunch of code, supported by a bunch of compilers 
(including
Apple's gcc-2.95.2).  Yes, it's ugly, but it's out there in the real 
world.

> no problem.  Feel free to maintain your own tree with whatever 
> extensions
> you want - it's Free Software.  But I will vote against any suggestion 
> to

Well, we do have a local tree, and it is a royal pain to maintain in sync
with the FSF, as Stan can attest. :)  In making my proposal, I assumed
(perhaps wrongly) that a lot of other organizations are in the same 
boat --
i.e., they have local modifications that they wouldn't mind putting into
the FSF, but can't because GCC is not sufficiently modular (at least not
for the front-end things) and the local things can't be kept sufficiently
target-specific (hence interfering with the mainline).

--Zem
--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085

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

[Stan Shebs]

Per Bothner wrote:
> 
> Why would we want to put into our compiler a TARGET-SPECIFIC syntactic
> extension to handle the rather generic concept of a fixed-size vector?
>  And why
> would we want to add a configure mechanism to do that?
> 
> Let me answer for you:  We don't.

Who's this "we" you're referring to?  It can't be the body of GCC
contributors, because Zem is in that group, and it's not the
maintainers, because I haven't decided yet - I'm interested
in the arguments for and against.  If the "we" refers to an SC
decision, you should say so explicitly.

Zem's proposal does challenge GCC orthodoxy, but in the past
you've been the one to question the rules imposed by other people.
Surely he deserves the opportunity to make his case, and as the
discussion today shows, there continues not to be a consensus on
whether it's even possible to have generic syntax for vectors,
so you can hardly fault him for trying to come up with creative
ideas to resolve this longstanding impasse.

Stan

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

[Joseph S. Myers]

On Tue, 27 Nov 2001, Stan Shebs wrote:

> > Why would we want to put into our compiler a TARGET-SPECIFIC syntactic
> > extension to handle the rather generic concept of a fixed-size vector?
> >  And why
> > would we want to add a configure mechanism to do that?
> > 
> > Let me answer for you:  We don't.
> 
> Who's this "we" you're referring to?  It can't be the body of GCC
> contributors, because Zem is in that group, and it's not the

Perhaps it's the Mission Statement which says

          + Patches will be considered equally based on their technical
            merits.

along with the accepted notion of technical merits that
machine-independent files shouldn't contain target-specific code, only
feature-specific code (see portability.texi and codingconventions.html).
The technical merits of a patch include those of the design of any feature
it implements and it's perfectly reasonable to object to badly designed
proposed features before there's an explicit patch.  It should be clear
that a good design would provide interfaces that allow for the variety of
vector types on different processors and don't do violence to the existing
C syntax or semantics.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

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

[Joseph S. Myers]

On Tue, 27 Nov 2001, Stan Shebs wrote:

> > Why would we want to put into our compiler a TARGET-SPECIFIC syntactic
> > extension to handle the rather generic concept of a fixed-size vector?
> >  And why
> > would we want to add a configure mechanism to do that?
> > 
> > Let me answer for you:  We don't.
> 
> Who's this "we" you're referring to?  It can't be the body of GCC
> contributors, because Zem is in that group, and it's not the

Perhaps it's the Mission Statement which says

          + Patches will be considered equally based on their technical
            merits.

along with the accepted notion of technical merits that
machine-independent files shouldn't contain target-specific code, only
feature-specific code (see portability.texi and codingconventions.html).
The technical merits of a patch include those of the design of any feature
it implements and it's perfectly reasonable to object to badly designed
proposed features before there's an explicit patch.  It should be clear
that a good design would provide interfaces that allow for the variety of
vector types on different processors and don't do violence to the existing
C syntax or semantics.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

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

[Per Bothner]

Stan Shebs wrote:

>Per Bothner wrote:
>
>>Why would we want to put into our compiler a TARGET-SPECIFIC syntactic
>>extension to handle the rather generic concept of a fixed-size vector?
>> And why
>>would we want to add a configure mechanism to do that?
>>
>>Let me answer for you:  We don't.
>>
>Who's this "we" you're referring to?  It can't be the body of GCC
>contributors, because Zem is in that group, and it's not the
>maintainers, because I haven't decided yet - I'm interested
>in the arguments for and against.  If the "we" refers to an SC
>decision, you should say so explicitly.
>
"We" means "all Right-Thinking People", of course! :-)

By "we" I meant "Per Bothner and those who agree with him"!   I guess
and hope that the latter might in this case would include "most of the
experienced gcc maintainers and most members of the Gcc steering
committe" but I don't know for sure.  I could be wrong, both about this
issue, and what other people (would) feel about it.

>Zem's proposal does challenge GCC orthodoxy, but in the past
>you've been the one to question the rules imposed by other people.
>
We're not talking rules here - except those of taste.

>Surely he deserves the opportunity to make his case,
>
He has made his case.  He admits it is not a clean extension, but
justifies his case by legacy code.  I don't think that is a strong enough
case - you yourself has suggested the amount of such code cannot
be very large.

> and as the
>discussion today shows, there continues not to be a consensus on
>whether it's even possible to have generic syntax for vectors,
>so you can hardly fault him for trying to come up with creative
>ideas to resolve this longstanding impasse.
>
I don't fault him at all.  If I were in his unfortunate position I might do
the same.  I just don't think what he is proposing is a good idea.

    --Per

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

[Per Bothner]

Stan Shebs wrote:

>Per Bothner wrote:
>
>>Why would we want to put into our compiler a TARGET-SPECIFIC syntactic
>>extension to handle the rather generic concept of a fixed-size vector?
>> And why
>>would we want to add a configure mechanism to do that?
>>
>>Let me answer for you:  We don't.
>>
>Who's this "we" you're referring to?  It can't be the body of GCC
>contributors, because Zem is in that group, and it's not the
>maintainers, because I haven't decided yet - I'm interested
>in the arguments for and against.  If the "we" refers to an SC
>decision, you should say so explicitly.
>
"We" means "all Right-Thinking People", of course! :-)

By "we" I meant "Per Bothner and those who agree with him"!   I guess
and hope that the latter might in this case would include "most of the
experienced gcc maintainers and most members of the Gcc steering
committe" but I don't know for sure.  I could be wrong, both about this
issue, and what other people (would) feel about it.

>Zem's proposal does challenge GCC orthodoxy, but in the past
>you've been the one to question the rules imposed by other people.
>
We're not talking rules here - except those of taste.

>Surely he deserves the opportunity to make his case,
>
He has made his case.  He admits it is not a clean extension, but
justifies his case by legacy code.  I don't think that is a strong enough
case - you yourself has suggested the amount of such code cannot
be very large.

> and as the
>discussion today shows, there continues not to be a consensus on
>whether it's even possible to have generic syntax for vectors,
>so you can hardly fault him for trying to come up with creative
>ideas to resolve this longstanding impasse.
>
I don't fault him at all.  If I were in his unfortunate position I might do
the same.  I just don't think what he is proposing is a good idea.

    --Per

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

[Mark Mitchell]

>> Let me answer for you:  We don't.
>
> Who's this "we" you're referring to?
>
> Zem's proposal does challenge GCC orthodoxy, but in the past
> you've been the one to question the rules imposed by other people.

Let's be very careful to keep this polite.  It's right on the edge
at the moment; everyone is getting tense.  No SHOUTING, please; and
let's not try to shut anyone up either.

Let's try a different tack.  What are we going to do about:

 (vector int)(1, 2, 3, 4)

Are we going to try to accept this syntax, or require the C99-like:

 (vector int){1, 2, 3, 4}

If the latter, then we have a source-incompatible change.  Once we
do that, all Altivec users have to change their code, and changing
"vector int" into "__attribute__((vector(4)) int" is not a whole
lot worse.

I think the fundamental question is not what to do about vector;
it's whether or not we're going to try to implement the Altivec
syntax or just its semantics.

It seems that most people would prefer the latter, but that the folks
at Apple would prefer the former.  Apple would like to stop having
to merge the Altivec patches, and they do not seem to believe that
users will be willing to change their code.  Is that right?

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

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

[Aldy Hernandez]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

 > Let's try a different tack.  What are we going to do about:

 >  (vector int)(1, 2, 3, 4)

...not going to be supported on fsf sources.  Too ugly.  Nobody can
intellectually reconcile the above nastiness.

I need to implement the above anyhow, but i suppose it will be
provided on additional set of, i suppose, apple+redhat supported
patches, never to be incorporated into gcc.

 > Are we going to try to accept this syntax, or require the C99-like:

 >  (vector int){1, 2, 3, 4}

yes

 > If the latter, then we have a source-incompatible change.  Once we
 > do that, all Altivec users have to change their code, and changing
 > "vector int" into "__attribute__((vector(4)) int" is not a whole
 > lot worse.

See the last response by rth.  He came up with a way in which we can
just specify the total vector size in an attribute and determine the
vector mode from the type being modified (int, in this case).  So, we
should be able to cater to both parties-- a more generic approach, and
a few macros to implement altivec syntax, modulo the () initializers.

 > It seems that most people would prefer the latter, but that the folks
 > at Apple would prefer the former.  Apple would like to stop having
 > to merge the Altivec patches, and they do not seem to believe that
 > users will be willing to change their code.  Is that right?

Yes, but after all this discussion, everything seems to have fallen into
place with the exception of "(1, 2, 3, 4)".  So these will have to be
provided for in external patches.

Aldy

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

[Mark Mitchell]

>
>  > If the latter, then we have a source-incompatible change.  Once we
>  > do that, all Altivec users have to change their code, and changing
>  > "vector int" into "__attribute__((vector(4)) int" is not a whole
>  > lot worse.
>
> See the last response by rth.  He came up with a way in which we can
> just specify the total vector size in an attribute and determine the
> vector mode from the type being modified (int, in this case).  So, we
> should be able to cater to both parties-- a more generic approach, and
> a few macros to implement altivec syntax, modulo the () initializers.

Good.  Note that I (and probably Joseph) are going to get unhappy if
there is not detailed documentation about exactly what the syntax
means, and also exactly what the semantics are for these types. :-)

Thanks,

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

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

[Aldy Hernandez]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

 > Let's try a different tack.  What are we going to do about:

 >  (vector int)(1, 2, 3, 4)

...not going to be supported on fsf sources.  Too ugly.  Nobody can
intellectually reconcile the above nastiness.

I need to implement the above anyhow, but i suppose it will be
provided on additional set of, i suppose, apple+redhat supported
patches, never to be incorporated into gcc.

 > Are we going to try to accept this syntax, or require the C99-like:

 >  (vector int){1, 2, 3, 4}

yes

 > If the latter, then we have a source-incompatible change.  Once we
 > do that, all Altivec users have to change their code, and changing
 > "vector int" into "__attribute__((vector(4)) int" is not a whole
 > lot worse.

See the last response by rth.  He came up with a way in which we can
just specify the total vector size in an attribute and determine the
vector mode from the type being modified (int, in this case).  So, we
should be able to cater to both parties-- a more generic approach, and
a few macros to implement altivec syntax, modulo the () initializers.

 > It seems that most people would prefer the latter, but that the folks
 > at Apple would prefer the former.  Apple would like to stop having
 > to merge the Altivec patches, and they do not seem to believe that
 > users will be willing to change their code.  Is that right?

Yes, but after all this discussion, everything seems to have fallen into
place with the exception of "(1, 2, 3, 4)".  So these will have to be
provided for in external patches.

Aldy

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

[Stan Shebs]

Mark Mitchell wrote:
> 
> I think the fundamental question is not what to do about vector;
> it's whether or not we're going to try to implement the Altivec
> syntax or just its semantics.

Yep.

> It seems that most people would prefer the latter, but that the folks
> at Apple would prefer the former.  Apple would like to stop having
> to merge the Altivec patches, and they do not seem to believe that
> users will be willing to change their code.  Is that right?

More or less.  I don't consider merging to be a big issue; it's a
cost of doing business, and I'm prepared to maintain a set of
frontend hacks forever if necessary.

It's a more important problem that if we do nothing, PowerPC
developers will see three different versions of GCC; an FSF release,
a Red Hat release, and an Apple release, each with different forms
of support for AltiVec programming.  It's already the case that
some versions of PowerPC Linux ship with two compilers, one with
Motorola patches and one without, and each based on a different
release of GCC.  If AltiVec developers have to write three-way ifdefs
for every single source construct because we haven't been able to
come to some sort of agreement on what to support, they're not going
to praise some GCC maintainers and criticize others; we're all going
to come in for criticism, because users are not really interested in
our little internal disputes.

Now I believe that we do have some leeway to update the AltiVec
extension syntax, based on what I know of the size of our installed
base and how the code is written.  If there is a compromise that
allows us to have one version of GCC instead of three, and requires
only minor edits of source (such as {} instead of () for constants),
I think we will be able to get our users to adopt it.

Stan

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

[Mark Mitchell]

> Now I believe that we do have some leeway to update the AltiVec
> extension syntax, based on what I know of the size of our installed
> base and how the code is written.  If there is a compromise that
> allows us to have one version of GCC instead of three, and requires
> only minor edits of source (such as {} instead of () for constants),
> I think we will be able to get our users to adopt it.

Good.  In that case, I think we have a plan -- go with Richard's
attribute syntax, which, with appropriate macroization, gets very
close to the Altivec syntax.

Thanks,

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

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

[Dale Johannesen]

> Now I believe that we do have some leeway to update the AltiVec
> extension syntax, based on what I know of the size of our installed
> base and how the code is written.  If there is a compromise that
> allows us to have one version of GCC instead of three, and requires
> only minor edits of source (such as {} instead of () for constants),
> I think we will be able to get our users to adopt it.

I think the only way our users will adopt a change is if they have no
choice, and then they will resent it.  I haven't asked them, and neither
has Stan, I don't think, but from what I've seen they are not much
interested in issues of language theory.  They just want their code to
work, and will regard a necessary change to working code as a big minus
with no perceptible benefit to them.  I even sympathize; they do have
schedules and limited resources.

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

[Stan Shebs]

Dale Johannesen wrote:
> 
> > Now I believe that we do have some leeway to update the AltiVec
> > extension syntax, based on what I know of the size of our installed
> > base and how the code is written.  If there is a compromise that
> > allows us to have one version of GCC instead of three, and requires
> > only minor edits of source (such as {} instead of () for constants),
> > I think we will be able to get our users to adopt it.
> 
> I think the only way our users will adopt a change is if they have no
> choice, and then they will resent it.  I haven't asked them, and neither
> has Stan, I don't think, but from what I've seen they are not much
> interested in issues of language theory.  They just want their code to
> work, and will regard a necessary change to working code as a big minus
> with no perceptible benefit to them.  I even sympathize; they do have
> schedules and limited resources.

In practice, Mac developers will get a nice long transition period.
To use {} vs () as an example, I expect we will support both,
eventually deprecating ().  People interested in Linux compatibility
can start using {} right away, those who are more concerned about
Metrowerks compat can stay with ().

Stan

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

[Syd Polk]

On Wednesday, November 28, 2001, at 11:54 , Stan Shebs wrote:

> Dale Johannesen wrote:
>>
>>> Now I believe that we do have some leeway to update the AltiVec
>>> extension syntax, based on what I know of the size of our installed
>>> base and how the code is written.  If there is a compromise that
>>> allows us to have one version of GCC instead of three, and requires
>>> only minor edits of source (such as {} instead of () for constants),
>>> I think we will be able to get our users to adopt it.
>>
>> I think the only way our users will adopt a change is if they have no
>> choice, and then they will resent it.  I haven't asked them, and 
>> neither
>> has Stan, I don't think, but from what I've seen they are not much
>> interested in issues of language theory.  They just want their code to
>> work, and will regard a necessary change to working code as a big minus
>> with no perceptible benefit to them.  I even sympathize; they do have
>> schedules and limited resources.
>
> In practice, Mac developers will get a nice long transition period.
> To use {} vs () as an example, I expect we will support both,
> eventually deprecating ().  People interested in Linux compatibility
> can start using {} right away, those who are more concerned about
> Metrowerks compat can stay with ().
>
> Stan
>

I think the fact that gcc3 code generates code that runs as fast or 
faster than other compilers will convince people to make source code 
changes. The people that use -altivec are the most performance oriented 
people, and as such, are willing to do a lot to squeeze out a few more 
cycles.

>
Syd Polk
QA and Integration Manager, Mac OSX Development Tools
+1 408 974-0577

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

[Tim Hollebeek]

> I think the fact that gcc3 code generates code that runs as fast or 
> faster than other compilers will convince people to make source code 
> changes.

People feel a sense of ownership over their source code, and resent
being forced to take the time to change it.

Expecting users to make source code changes has been the death of many
a compiler, no matter how advanced.

Tim Hollebeek

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

[Tim Hollebeek]

> I think the fact that gcc3 code generates code that runs as fast or 
> faster than other compilers will convince people to make source code 
> changes.

People feel a sense of ownership over their source code, and resent
being forced to take the time to change it.

Expecting users to make source code changes has been the death of many
a compiler, no matter how advanced.

Tim Hollebeek

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

[Syd Polk]

On Wednesday, November 28, 2001, at 11:54 , Stan Shebs wrote:

> Dale Johannesen wrote:
>>
>>> Now I believe that we do have some leeway to update the AltiVec
>>> extension syntax, based on what I know of the size of our installed
>>> base and how the code is written.  If there is a compromise that
>>> allows us to have one version of GCC instead of three, and requires
>>> only minor edits of source (such as {} instead of () for constants),
>>> I think we will be able to get our users to adopt it.
>>
>> I think the only way our users will adopt a change is if they have no
>> choice, and then they will resent it.  I haven't asked them, and 
>> neither
>> has Stan, I don't think, but from what I've seen they are not much
>> interested in issues of language theory.  They just want their code to
>> work, and will regard a necessary change to working code as a big minus
>> with no perceptible benefit to them.  I even sympathize; they do have
>> schedules and limited resources.
>
> In practice, Mac developers will get a nice long transition period.
> To use {} vs () as an example, I expect we will support both,
> eventually deprecating ().  People interested in Linux compatibility
> can start using {} right away, those who are more concerned about
> Metrowerks compat can stay with ().
>
> Stan
>

I think the fact that gcc3 code generates code that runs as fast or 
faster than other compilers will convince people to make source code 
changes. The people that use -altivec are the most performance oriented 
people, and as such, are willing to do a lot to squeeze out a few more 
cycles.

>
Syd Polk
QA and Integration Manager, Mac OSX Development Tools
+1 408 974-0577

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

[Stan Shebs]

Dale Johannesen wrote:
> 
> > Now I believe that we do have some leeway to update the AltiVec
> > extension syntax, based on what I know of the size of our installed
> > base and how the code is written.  If there is a compromise that
> > allows us to have one version of GCC instead of three, and requires
> > only minor edits of source (such as {} instead of () for constants),
> > I think we will be able to get our users to adopt it.
> 
> I think the only way our users will adopt a change is if they have no
> choice, and then they will resent it.  I haven't asked them, and neither
> has Stan, I don't think, but from what I've seen they are not much
> interested in issues of language theory.  They just want their code to
> work, and will regard a necessary change to working code as a big minus
> with no perceptible benefit to them.  I even sympathize; they do have
> schedules and limited resources.

In practice, Mac developers will get a nice long transition period.
To use {} vs () as an example, I expect we will support both,
eventually deprecating ().  People interested in Linux compatibility
can start using {} right away, those who are more concerned about
Metrowerks compat can stay with ().

Stan

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

[Dale Johannesen]

> Now I believe that we do have some leeway to update the AltiVec
> extension syntax, based on what I know of the size of our installed
> base and how the code is written.  If there is a compromise that
> allows us to have one version of GCC instead of three, and requires
> only minor edits of source (such as {} instead of () for constants),
> I think we will be able to get our users to adopt it.

I think the only way our users will adopt a change is if they have no
choice, and then they will resent it.  I haven't asked them, and neither
has Stan, I don't think, but from what I've seen they are not much
interested in issues of language theory.  They just want their code to
work, and will regard a necessary change to working code as a big minus
with no perceptible benefit to them.  I even sympathize; they do have
schedules and limited resources.

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

[Stan Shebs]

Mark Mitchell wrote:
> 
> I think the fundamental question is not what to do about vector;
> it's whether or not we're going to try to implement the Altivec
> syntax or just its semantics.

Yep.

> It seems that most people would prefer the latter, but that the folks
> at Apple would prefer the former.  Apple would like to stop having
> to merge the Altivec patches, and they do not seem to believe that
> users will be willing to change their code.  Is that right?

More or less.  I don't consider merging to be a big issue; it's a
cost of doing business, and I'm prepared to maintain a set of
frontend hacks forever if necessary.

It's a more important problem that if we do nothing, PowerPC
developers will see three different versions of GCC; an FSF release,
a Red Hat release, and an Apple release, each with different forms
of support for AltiVec programming.  It's already the case that
some versions of PowerPC Linux ship with two compilers, one with
Motorola patches and one without, and each based on a different
release of GCC.  If AltiVec developers have to write three-way ifdefs
for every single source construct because we haven't been able to
come to some sort of agreement on what to support, they're not going
to praise some GCC maintainers and criticize others; we're all going
to come in for criticism, because users are not really interested in
our little internal disputes.

Now I believe that we do have some leeway to update the AltiVec
extension syntax, based on what I know of the size of our installed
base and how the code is written.  If there is a compromise that
allows us to have one version of GCC instead of three, and requires
only minor edits of source (such as {} instead of () for constants),
I think we will be able to get our users to adopt it.

Stan

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

[Stan Shebs]

Per Bothner wrote:
> 
> Why would we want to put into our compiler a TARGET-SPECIFIC syntactic
> extension to handle the rather generic concept of a fixed-size vector?
>  And why
> would we want to add a configure mechanism to do that?
> 
> Let me answer for you:  We don't.

Who's this "we" you're referring to?  It can't be the body of GCC
contributors, because Zem is in that group, and it's not the
maintainers, because I haven't decided yet - I'm interested
in the arguments for and against.  If the "we" refers to an SC
decision, you should say so explicitly.

Zem's proposal does challenge GCC orthodoxy, but in the past
you've been the one to question the rules imposed by other people.
Surely he deserves the opportunity to make his case, and as the
discussion today shows, there continues not to be a consensus on
whether it's even possible to have generic syntax for vectors,
so you can hardly fault him for trying to come up with creative
ideas to resolve this longstanding impasse.

Stan

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

[Per Bothner]

Ziemowit Laski wrote:

> No! :) The features were are talking about here are TARGET-SPECIFIC 
> and hence need not
> be any more portable, well-defined, documented, etc., than the machine 
> descriptions
> for those targets. 

Why would we want to put into our compiler a TARGET-SPECIFIC syntactic
extension to handle the rather generic concept of a fixed-size vector? 
 And why
would we want to add a configure mechanism to do that?

Let me answer for you:  We don't.

What we want is a *generic* machine-independent syntax, with optional
target-specfic optimization patterns.  If you don't want to or can't do 
that,
no problem.  Feel free to maintain your own tree with whatever extensions
you want - it's Free Software.  But I will vote against any suggestion to
allow such code to be checkled into the CVS mainline.

    --Per Bothner

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

[Ziemowit Laski]

On Tuesday, November 27, 2001, at 11:16 , Per Bothner wrote:

> Ira Ruben wrote:
>
>> At 9:47 AM -0800 11/27/01, Stan Shebs wrote:
>>
>> I'm not going to get into a debate with you about design decisions of 
>> the past when you weren't there and don't know the context in which 
>> those were made.  It may be your opinion about how "hard" it is to 
>> support "vector" this way.
>
> You're missing the point, which is not how easy or hard it is to 
> implement
> the feature.  The hard part is coming up with an acceptable, 
> well-defined,
> documented, portable feature that makes sense in the context of gcc,
> that can be maintained, and that you can get the gcc maintainers to 
> agree to.

No! :) The features were are talking about here are TARGET-SPECIFIC and 
hence need not
be any more portable, well-defined, documented, etc., than the machine 
descriptions
for those targets.  The people concerned with AltiVec keywords will be, 
for the most
part, the same group that is concerned with the contents of 
gcc/config/rs6000/rs6000.md.

The idea here is to find a way in which people NOT concerned with 
AltiVec do not ever have
to lay their eyes on an AltiVec keyword (just as they don't have to look 
at rs6000.md).
This is the essence of my proposal.

--Zem
--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085

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

[Per Bothner]

Ira Ruben wrote:

> At 9:47 AM -0800 11/27/01, Stan Shebs wrote:
>
> I'm not going to get into a debate with you about design decisions of 
> the past when you weren't there and don't know the context in which 
> those were made.  It may be your opinion about how "hard" it is to 
> support "vector" this way. 

You're missing the point, which is not how easy or hard it is to implement
the feature.  The hard part is coming up with an acceptable, well-defined,
documented, portable feature that makes sense in the context of gcc,
that can be maintained, and that you can get the gcc maintainers to 
agree to.

> I do not agree.  If it was so easy for MrC[pp] and I assume Mcc and MW 
> I do not see a problem with gcc.

Perhaps because we here have a longer-term perspective, or because we 
have different
priorities.  We support vastly more targets than they do.

    --Per Bothner

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

[Ziemowit Laski]

On Tuesday, November 27, 2001, at 09:47 , Stan Shebs wrote:

> I wasn't going to mention your name, but if you want to take
> credit I can't stop you... :-)

I likewise held my peace, but now that the cat is out of the bag... :) :)
>
>> For MrC[pp] is was easy to do.  And it was based on
>> feedback from our internal (Apple) AltiVec users (the *only* users at
>> that time other than Moto).  They didn't want to write __vector and
>> they certainly couldn't tolerate "vector" being a macro that expanded
>> to __vector (which Moto was proposing).  And "vector" couldn't be
>> treated as an unconditional reserved word either.
>
> Nevertheless, I still think it was a mistake.  When it comes to
> messing with the language, we often need to say "no" to users, who

I agree that Ira's 'vector' (as opposed to '__vector') was not the
cleanest way to approach this (although not nearly as nefarious as
'#pragma poison'), but THIS IS TOTALLY BESIDE THE POINT!

My point (or, perhaps, points) were:
   1. GCC is used on a variety of real-world platforms
   2. In that same real world, people have invented tons of
      target-specific extensions to C and C++ to get extra mileage
      out of their particular hardware/OS setup.
   3. Ergo, we should be able to come up with a 'configure'-based
      mechanism for enabling selected extensions for selected target
      WHILE LEAVING THEM HIDDEN FROM MAINLINE USERS.

How could we go about step 3?  I'm sure there are a million ways,
but let me illustrate one possible scenario (for AltiVec):
   1. We create a file called gcc/config/rs6000/c-parse.in.diff
      (and something analogous for C++)
   2. At build time, this diff will be used to patch up
      gcc/c-parse.in if needed.

The foregoing approach has two immediate consequences:
   1. The mainline grammar/lexical analyzer remains unchanged
   2. It will be the sole responsibility of the users of AltiVec
      extensions to maintain the diff so that it can be applied
      cleanly; mainline developers need not and SHOULD NOT be
      forced to deal with this.

> the world?  Ironically, this extension makes our internal version of
> GCC more complicated and time-consuming to merge with FSF sources, so
> our imports take longer and have more problems, which means that your
> own daily work today has been made more difficult by the expedient
> choice of several years ago.

True, but I suspect that we (i.e., Apple) are far from the only ones
in this situation, which is why it is so desirable, IMHO, to be
able to put all such target-specific stuff in the FSF tree to begin
with!  Of course, we already do this for back-end/codegen stuff -- we
just need to generalize this model.

--Zem
--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085

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

[Joseph S. Myers]

On Tue, 27 Nov 2001, Ziemowit Laski wrote:

> My point (or, perhaps, points) were:
>    1. GCC is used on a variety of real-world platforms
>    2. In that same real world, people have invented tons of
>       target-specific extensions to C and C++ to get extra mileage
>       out of their particular hardware/OS setup.
>    3. Ergo, we should be able to come up with a 'configure'-based
>       mechanism for enabling selected extensions for selected target
>       WHILE LEAVING THEM HIDDEN FROM MAINLINE USERS.

We should never accept dirty extensions on the basis that some other
compilers have them.  Target attributes, pragmas and built-in functions
provide well-defined ways of using target-specific features without
causing problems for the rest of the compiler.

If we accept anything like this feature in GCC, it should be clean and
well-defined.  The feature as it is at present - a mess - apparently comes
from a multi-vendor language model.  Where is the specification?  What are
its Defect Report procedures for dealing with interpretation of
ambiguities or defects?  For something GCC-specific we can simply discuss
it on the gcc list then declare a convenient answer, but if it is meant to
be compatible with other compilers there should be a proper system.

> How could we go about step 3?  I'm sure there are a million ways,
> but let me illustrate one possible scenario (for AltiVec):
>    1. We create a file called gcc/config/rs6000/c-parse.in.diff
>       (and something analogous for C++)

If you're distributing diffs (and these would need to cover a lot more
files), just make them available by HTTP and link to them from
extensions.html.  No need for them to go in the tree.

>    2. At build time, this diff will be used to patch up
>       gcc/c-parse.in if needed.

The established practice is that users building releases do not need to
have Bison installed.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

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

[Stan Shebs]

"Joseph S. Myers" wrote:
> 
> If we accept anything like this feature in GCC, it should be clean and
> well-defined.  The feature as it is at present - a mess - apparently comes
> from a multi-vendor language model.  Where is the specification?

All at www.altivec.org, including the 260-page programming interface
specification.  I'm sure you'll find plenty of loopholes in it
though.

Stan

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

[Joseph S. Myers]

On Tue, 27 Nov 2001, Stan Shebs wrote:

> All at www.altivec.org, including the 260-page programming interface
> specification.  I'm sure you'll find plenty of loopholes in it
> though.

It doesn't include anything in the way of textual changes to the standards
or details of which syntax productions what new features are supposed to
go in.  This means such fundamental information is missing as:

* With context-sensitive keywords, after "typedef int vector;", is vector 
a keyword or a typedef?

* With context-sensitive keywords, after "int vector;", is "(vector)+1" to 
be interpreted as addition, or a cast (which would seem to parse according 
to the syntax, but violate constraints)?

* Do vector literals bind more or less tightly than sizeof?  GCC used to
handle compound literals incorrectly in this case
(gcc.c-torture/compile/20010124-1.c).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

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

[Aldy Hernandez]

>>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:


 > * With context-sensitive keywords, after "typedef int vector;", is vector 
 > a keyword or a typedef?

You can't typedef vector in the altivec specs.

 > * Do vector literals bind more or less tightly than sizeof?  GCC used to
 > handle compound literals incorrectly in this case
 > (gcc.c-torture/compile/20010124-1.c).

You can't do sizeof() vector literals i don't think.  Just sizeof's of
vectors or sizeof vector pointers.

Aldy

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

[Dale Johannesen]

On Tuesday, November 27, 2001, at 01:58 PM, Aldy Hernandez wrote:

>>>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:
>
>
>> * With context-sensitive keywords, after "typedef int vector;", is vector
>> a keyword or a typedef?
>
> You can't typedef vector in the altivec specs.

The Moto docs (PIM on the website) give two ways to do it, in 2.2.1 and 2.
2.2.
You're apparently trying to use 2.2.1, where "vector" is a predefined 
macro.
Apple/Moto's implementation is based on 2.2.2, where "vector" is a 
context-sensitive
keyword.  IMO the 2.2.2 way is clearly better, well, less bad anyway; it 
does
allow the user to use 'vector' in many other places, as he is supposed to 
be able
to do.  In particular 'typedef int vector;' works, and AFAIK the STL use of
"vector" also works, although I don't think anybody's exercised it much.  
The
PIM doesn't explain things very well, but what happens is that "vector" is 
a
keyword only when it's at the beginning of a type specification, and only
when followed by certain other keywords, as listed in the PIM.  Thus:

typedef int vector;
vector x;               /* int */
vector unsigned int y;  /* Altivec vector */

And sure enough it works that way.  I think the way the new syntax works,
it is actually unambiguous, although that isn't obvious (Ira eventually 
convinced
me :)  I further think the context-sensitive keyword implementation does 
not break
any standard-conforming use of "vector" as an identifier; it only makes 
legal
some constructs that are errors according to the standard.  (This does not
mean I think it was a good idea; I don't.  But it does work.)

| "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:
|
| * With context-sensitive keywords, after "int vector;", is "(vector)+1" 
to
| be interpreted as addition, or a cast (which would seem to parse 
according
| to the syntax, but violate constraints)?

Addition.  (vector) is not a cast because "vector" does not indicate a 
type here,
since it isn't followed by any of the other magic words.

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

[Dale Johannesen]

On Tuesday, November 27, 2001, at 01:58 PM, Aldy Hernandez wrote:

>>>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:
>
>
>> * With context-sensitive keywords, after "typedef int vector;", is vector
>> a keyword or a typedef?
>
> You can't typedef vector in the altivec specs.

The Moto docs (PIM on the website) give two ways to do it, in 2.2.1 and 2.
2.2.
You're apparently trying to use 2.2.1, where "vector" is a predefined 
macro.
Apple/Moto's implementation is based on 2.2.2, where "vector" is a 
context-sensitive
keyword.  IMO the 2.2.2 way is clearly better, well, less bad anyway; it 
does
allow the user to use 'vector' in many other places, as he is supposed to 
be able
to do.  In particular 'typedef int vector;' works, and AFAIK the STL use of
"vector" also works, although I don't think anybody's exercised it much.  
The
PIM doesn't explain things very well, but what happens is that "vector" is 
a
keyword only when it's at the beginning of a type specification, and only
when followed by certain other keywords, as listed in the PIM.  Thus:

typedef int vector;
vector x;               /* int */
vector unsigned int y;  /* Altivec vector */

And sure enough it works that way.  I think the way the new syntax works,
it is actually unambiguous, although that isn't obvious (Ira eventually 
convinced
me :)  I further think the context-sensitive keyword implementation does 
not break
any standard-conforming use of "vector" as an identifier; it only makes 
legal
some constructs that are errors according to the standard.  (This does not
mean I think it was a good idea; I don't.  But it does work.)

| "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:
|
| * With context-sensitive keywords, after "int vector;", is "(vector)+1" 
to
| be interpreted as addition, or a cast (which would seem to parse 
according
| to the syntax, but violate constraints)?

Addition.  (vector) is not a cast because "vector" does not indicate a 
type here,
since it isn't followed by any of the other magic words.

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

[Aldy Hernandez]

>>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:


 > * With context-sensitive keywords, after "typedef int vector;", is vector 
 > a keyword or a typedef?

You can't typedef vector in the altivec specs.

 > * Do vector literals bind more or less tightly than sizeof?  GCC used to
 > handle compound literals incorrectly in this case
 > (gcc.c-torture/compile/20010124-1.c).

You can't do sizeof() vector literals i don't think.  Just sizeof's of
vectors or sizeof vector pointers.

Aldy

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

[Joseph S. Myers]

On Tue, 27 Nov 2001, Stan Shebs wrote:

> All at www.altivec.org, including the 260-page programming interface
> specification.  I'm sure you'll find plenty of loopholes in it
> though.

It doesn't include anything in the way of textual changes to the standards
or details of which syntax productions what new features are supposed to
go in.  This means such fundamental information is missing as:

* With context-sensitive keywords, after "typedef int vector;", is vector 
a keyword or a typedef?

* With context-sensitive keywords, after "int vector;", is "(vector)+1" to 
be interpreted as addition, or a cast (which would seem to parse according 
to the syntax, but violate constraints)?

* Do vector literals bind more or less tightly than sizeof?  GCC used to
handle compound literals incorrectly in this case
(gcc.c-torture/compile/20010124-1.c).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

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

[Stan Shebs]

"Joseph S. Myers" wrote:
> 
> If we accept anything like this feature in GCC, it should be clean and
> well-defined.  The feature as it is at present - a mess - apparently comes
> from a multi-vendor language model.  Where is the specification?

All at www.altivec.org, including the 260-page programming interface
specification.  I'm sure you'll find plenty of loopholes in it
though.

Stan

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

[Ziemowit Laski]

On Tuesday, November 27, 2001, at 12:44 , Joseph S. Myers wrote:

> On Tue, 27 Nov 2001, Ziemowit Laski wrote:
>
>> My point (or, perhaps, points) were:
>>    1. GCC is used on a variety of real-world platforms
>>    2. In that same real world, people have invented tons of
>>       target-specific extensions to C and C++ to get extra mileage
>>       out of their particular hardware/OS setup.
>>    3. Ergo, we should be able to come up with a 'configure'-based
>>       mechanism for enabling selected extensions for selected target
>>       WHILE LEAVING THEM HIDDEN FROM MAINLINE USERS.
>
> We should never accept dirty extensions on the basis that some other
> compilers have them.  Target attributes, pragmas and built-in functions

And this is, I believe, the main philosophical divide in our little
discussion.  Yes, I absolutely agree that the extensions (some of them,
anyway) are dirty.  But:
   1.  The exist and are used in the real world.
   2.  C and C++ are not exactly paragons of cleanliness (which, of 
course,
       is why they too are used in the real world).  If I wanted clean,
       I'd stick to Ada-95.

> provide well-defined ways of using target-specific features without
> causing problems for the rest of the compiler.

The main thrust of my proposal has been to create a mechanism intended
PRECISELY to prevent problems for the rest of the compiler.
>
> If we accept anything like this feature in GCC, it should be clean and
> well-defined.  The feature as it is at present - a mess - apparently 
> comes
> from a multi-vendor language model.  Where is the specification?  What 
> are

See my previous posting for an explanation of why this is not relevant.

> If you're distributing diffs (and these would need to cover a lot more
> files), just make them available by HTTP and link to them from
> extensions.html.  No need for them to go in the tree.

But is there any harm in INCLUDING them in the tree?
>
>>    2. At build time, this diff will be used to patch up
>>       gcc/c-parse.in if needed.
>
> The established practice is that users building releases do not need to
> have Bison installed.

And users not needing AltiVec will not need Bison.  And those who DO need
AltiVec will have the responsibility to install Bison on their system.

--Zem
--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085

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

[Richard Henderson]

On Tue, Nov 27, 2001 at 01:19:24PM -0800, Ziemowit Laski wrote:
> > provide well-defined ways of using target-specific features without
> > causing problems for the rest of the compiler.
> 
> The main thrust of my proposal has been to create a mechanism intended
> PRECISELY to prevent problems for the rest of the compiler.

Nevertheless, there are many other targets for gcc that do support some
form of SIMD, and thus we ought to come up with a solution that works
across all of them.

> But is there any harm in INCLUDING them in the tree?

I do not want to hack up our build mechanism.  It's already horrible.

Given that there appear to be several folks interested in this, it
might be acceptable to have an altivec branch in the regular gcc
repository, but that's as far as I'd be willing to let it go.


r~

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

[Richard Henderson]

On Tue, Nov 27, 2001 at 01:19:24PM -0800, Ziemowit Laski wrote:
> > provide well-defined ways of using target-specific features without
> > causing problems for the rest of the compiler.
> 
> The main thrust of my proposal has been to create a mechanism intended
> PRECISELY to prevent problems for the rest of the compiler.

Nevertheless, there are many other targets for gcc that do support some
form of SIMD, and thus we ought to come up with a solution that works
across all of them.

> But is there any harm in INCLUDING them in the tree?

I do not want to hack up our build mechanism.  It's already horrible.

Given that there appear to be several folks interested in this, it
might be acceptable to have an altivec branch in the regular gcc
repository, but that's as far as I'd be willing to let it go.


r~

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

[Mark Mitchell]

> But is there any harm in INCLUDING them in the tree?

Yes.  Absolutely every byte in the tree has a cost: we have to remember
what it's there for, where it's used, where it's not, and if anything
else changes that might affect it, we have to know about it, so that
we can fix it too, or at least consciously break it, rather than
unconsciously.

And if the answer is "It's OK, you can break it without thinking about
it" then it should just be a local patch in somebody else's tree.

That said the Altivec programming extensions are widely used at this
point, and I'm not sure how reasonable it is for us to say that we
want to support this stuff in some other way, even if we don't like
the way it was done.  (I don't.)

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.

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.

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

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

[Ziemowit Laski]

On Tuesday, November 27, 2001, at 12:44 , Joseph S. Myers wrote:

> On Tue, 27 Nov 2001, Ziemowit Laski wrote:
>
>> My point (or, perhaps, points) were:
>>    1. GCC is used on a variety of real-world platforms
>>    2. In that same real world, people have invented tons of
>>       target-specific extensions to C and C++ to get extra mileage
>>       out of their particular hardware/OS setup.
>>    3. Ergo, we should be able to come up with a 'configure'-based
>>       mechanism for enabling selected extensions for selected target
>>       WHILE LEAVING THEM HIDDEN FROM MAINLINE USERS.
>
> We should never accept dirty extensions on the basis that some other
> compilers have them.  Target attributes, pragmas and built-in functions

And this is, I believe, the main philosophical divide in our little
discussion.  Yes, I absolutely agree that the extensions (some of them,
anyway) are dirty.  But:
   1.  The exist and are used in the real world.
   2.  C and C++ are not exactly paragons of cleanliness (which, of 
course,
       is why they too are used in the real world).  If I wanted clean,
       I'd stick to Ada-95.

> provide well-defined ways of using target-specific features without
> causing problems for the rest of the compiler.

The main thrust of my proposal has been to create a mechanism intended
PRECISELY to prevent problems for the rest of the compiler.
>
> If we accept anything like this feature in GCC, it should be clean and
> well-defined.  The feature as it is at present - a mess - apparently 
> comes
> from a multi-vendor language model.  Where is the specification?  What 
> are

See my previous posting for an explanation of why this is not relevant.

> If you're distributing diffs (and these would need to cover a lot more
> files), just make them available by HTTP and link to them from
> extensions.html.  No need for them to go in the tree.

But is there any harm in INCLUDING them in the tree?
>
>>    2. At build time, this diff will be used to patch up
>>       gcc/c-parse.in if needed.
>
> The established practice is that users building releases do not need to
> have Bison installed.

And users not needing AltiVec will not need Bison.  And those who DO need
AltiVec will have the responsibility to install Bison on their system.

--Zem
--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085

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

[Joseph S. Myers]

On Tue, 27 Nov 2001, Ziemowit Laski wrote:

> My point (or, perhaps, points) were:
>    1. GCC is used on a variety of real-world platforms
>    2. In that same real world, people have invented tons of
>       target-specific extensions to C and C++ to get extra mileage
>       out of their particular hardware/OS setup.
>    3. Ergo, we should be able to come up with a 'configure'-based
>       mechanism for enabling selected extensions for selected target
>       WHILE LEAVING THEM HIDDEN FROM MAINLINE USERS.

We should never accept dirty extensions on the basis that some other
compilers have them.  Target attributes, pragmas and built-in functions
provide well-defined ways of using target-specific features without
causing problems for the rest of the compiler.

If we accept anything like this feature in GCC, it should be clean and
well-defined.  The feature as it is at present - a mess - apparently comes
from a multi-vendor language model.  Where is the specification?  What are
its Defect Report procedures for dealing with interpretation of
ambiguities or defects?  For something GCC-specific we can simply discuss
it on the gcc list then declare a convenient answer, but if it is meant to
be compatible with other compilers there should be a proper system.

> How could we go about step 3?  I'm sure there are a million ways,
> but let me illustrate one possible scenario (for AltiVec):
>    1. We create a file called gcc/config/rs6000/c-parse.in.diff
>       (and something analogous for C++)

If you're distributing diffs (and these would need to cover a lot more
files), just make them available by HTTP and link to them from
extensions.html.  No need for them to go in the tree.

>    2. At build time, this diff will be used to patch up
>       gcc/c-parse.in if needed.

The established practice is that users building releases do not need to
have Bison installed.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

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

[Aldy Hernandez]

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

 > How could we go about step 3?  I'm sure there are a million ways,
 > but let me illustrate one possible scenario (for AltiVec):
 >    1. We create a file called gcc/config/rs6000/c-parse.in.diff
 >       (and something analogous for C++)
 >    2. At build time, this diff will be used to patch up
 >       gcc/c-parse.in if needed.

This is a neat hack, but someone will still have to maintain a
separate set of patches for altivec stuff, which is what i'm trying to
avoid.

If we do the __vector stuff and come up with a generic way applicable
to all SIMD architectures, then we a) improve gcc b) do not cause a
maintenance nightmare.

It might be eaiser for Apple to keep separate trees because you only
support one target, and don't contribute your code as often as we do.

Be that as it may, even if we implement __vector correctly, we still
need patches for vector constant initializers, because there is just
no way in hell the following is going to be accepted:

        vector int foo = ((vector int)(1,2,3,4));

I assume we will add extensions with { }'s that will be incorporated
into gcc, but then have additional patches for ()'s that will never be
incorporated.

 >    2. It will be the sole responsibility of the users of AltiVec
 >       extensions to maintain the diff so that it can be applied
 >       cleanly; mainline developers need not and SHOULD NOT be
 >       forced to deal with this.

Let's try to try to come up with a generic solution, and then use your
approach for whatever we know will NEVER make it into mainline gcc.

 >> the world?  Ironically, this extension makes our internal version of
 >> GCC more complicated and time-consuming to merge with FSF sources, so
 >> our imports take longer and have more problems, which means that your
 >> own daily work today has been made more difficult by the expedient
 >> choice of several years ago.

 > True, but I suspect that we (i.e., Apple) are far from the only ones
 > in this situation, which is why it is so desirable, IMHO, to be
 > able to put all such target-specific stuff in the FSF tree to begin
 > with!  Of course, we already do this for back-end/codegen stuff -- we
 > just need to generalize this model.

It would be really nice if you guys contributed your internal changes
on a more regular basis.  Stan tells me there lots of Darwin
optimizations in the backend that you guys haven't contributed.  It's
just easier to get a better overall picture if we're all looking at
the same code base.

Aldy

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

[Stan Shebs]

Aldy Hernandez wrote:
> 
> Be that as it may, even if we implement __vector correctly, we still
> need patches for vector constant initializers, because there is just
> no way in hell the following is going to be accepted:
> 
>         vector int foo = ((vector int)(1,2,3,4));
> 
> I assume we will add extensions with { }'s that will be incorporated
> into gcc, but then have additional patches for ()'s that will never be
> incorporated.

You could always adopt the strategy of supporting it with the
additional patches, but deprecated, for a year, then drop it from
the next version.  If users get tangible benefits from switching,
they'll be ready to change.  (For instance, the possibility of
sharing at least some source with an SSE version...)

> It would be really nice if you guys contributed your internal changes
> on a more regular basis.  Stan tells me there lots of Darwin
> optimizations in the backend that you guys haven't contributed.  It's
> just easier to get a better overall picture if we're all looking at
> the same code base.

There aren't many backend changes not tied to other code that can't
be contributed, such as Motorola's AltiVec support.  But you're
right, we've been falling behind in contributing local changes.
Spending too much time arguing about controversial changes I guess... :-)

Stan

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

[Aldy Hernandez]

> You could always adopt the strategy of supporting it with the
> additional patches, but deprecated, for a year, then drop it from
> the next version.  If users get tangible benefits from switching,
> they'll be ready to change.  (For instance, the possibility of
> sharing at least some source with an SSE version...)

i would love to do this.  the problem is that i NEED to implement a way
of doing "vector int foo" (with no vector(xx) int foo) for my work.  so
if there's no way to accomplish this i'll have to come up with two sets
of patches: one to do "vector_size(4) int foo" (for fsf) and one to do
"vector int foo" for altivec for --well, for my day job.

i see no portable acceptable way of doing "vector int foo".

-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

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

[Dale Johannesen]

> i would love to do this.  the problem is that i NEED to implement a way
> of doing "vector int foo" (with no vector(xx) int foo) for my work.  so
> if there's no way to accomplish this i'll have to come up with two sets
> of patches: one to do "vector_size(4) int foo" (for fsf) and one to do
> "vector int foo" for altivec for --well, for my day job.
>
> i see no portable acceptable way of doing "vector int foo".

Actually "vector int foo" isn't acceptable according to the Moto docs;
you have to say "vector signed int foo" or "vector unsigned int foo"
explicitly.  And the Apple/Moto implementation follows the doc.  Do
you have to deal with existing code that uses "vector int foo"?

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

[Aldy Hernandez]

On Tue, 2001-11-27 at 19:06, Dale Johannesen wrote:
> 
> > i would love to do this.  the problem is that i NEED to implement a way
> > of doing "vector int foo" (with no vector(xx) int foo) for my work.  so
> > if there's no way to accomplish this i'll have to come up with two sets
> > of patches: one to do "vector_size(4) int foo" (for fsf) and one to do
> > "vector int foo" for altivec for --well, for my day job.
> >
> > i see no portable acceptable way of doing "vector int foo".
> 
> Actually "vector int foo" isn't acceptable according to the Moto docs;
> you have to say "vector signed int foo" or "vector unsigned int foo"
> explicitly.  And the Apple/Moto implementation follows the doc.  Do
> you have to deal with existing code that uses "vector int foo"?

ok, that's fine.  i probably misread.  i'm following the moto pim specs.


-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

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

[Aldy Hernandez]

On Tue, 2001-11-27 at 19:06, Dale Johannesen wrote:
> 
> > i would love to do this.  the problem is that i NEED to implement a way
> > of doing "vector int foo" (with no vector(xx) int foo) for my work.  so
> > if there's no way to accomplish this i'll have to come up with two sets
> > of patches: one to do "vector_size(4) int foo" (for fsf) and one to do
> > "vector int foo" for altivec for --well, for my day job.
> >
> > i see no portable acceptable way of doing "vector int foo".
> 
> Actually "vector int foo" isn't acceptable according to the Moto docs;
> you have to say "vector signed int foo" or "vector unsigned int foo"
> explicitly.  And the Apple/Moto implementation follows the doc.  Do
> you have to deal with existing code that uses "vector int foo"?

ok, that's fine.  i probably misread.  i'm following the moto pim specs.


-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

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

[Dale Johannesen]

> i would love to do this.  the problem is that i NEED to implement a way
> of doing "vector int foo" (with no vector(xx) int foo) for my work.  so
> if there's no way to accomplish this i'll have to come up with two sets
> of patches: one to do "vector_size(4) int foo" (for fsf) and one to do
> "vector int foo" for altivec for --well, for my day job.
>
> i see no portable acceptable way of doing "vector int foo".

Actually "vector int foo" isn't acceptable according to the Moto docs;
you have to say "vector signed int foo" or "vector unsigned int foo"
explicitly.  And the Apple/Moto implementation follows the doc.  Do
you have to deal with existing code that uses "vector int foo"?

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

[Aldy Hernandez]

> You could always adopt the strategy of supporting it with the
> additional patches, but deprecated, for a year, then drop it from
> the next version.  If users get tangible benefits from switching,
> they'll be ready to change.  (For instance, the possibility of
> sharing at least some source with an SSE version...)

i would love to do this.  the problem is that i NEED to implement a way
of doing "vector int foo" (with no vector(xx) int foo) for my work.  so
if there's no way to accomplish this i'll have to come up with two sets
of patches: one to do "vector_size(4) int foo" (for fsf) and one to do
"vector int foo" for altivec for --well, for my day job.

i see no portable acceptable way of doing "vector int foo".

-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

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

[Stan Shebs]

Aldy Hernandez wrote:
> 
> Be that as it may, even if we implement __vector correctly, we still
> need patches for vector constant initializers, because there is just
> no way in hell the following is going to be accepted:
> 
>         vector int foo = ((vector int)(1,2,3,4));
> 
> I assume we will add extensions with { }'s that will be incorporated
> into gcc, but then have additional patches for ()'s that will never be
> incorporated.

You could always adopt the strategy of supporting it with the
additional patches, but deprecated, for a year, then drop it from
the next version.  If users get tangible benefits from switching,
they'll be ready to change.  (For instance, the possibility of
sharing at least some source with an SSE version...)

> It would be really nice if you guys contributed your internal changes
> on a more regular basis.  Stan tells me there lots of Darwin
> optimizations in the backend that you guys haven't contributed.  It's
> just easier to get a better overall picture if we're all looking at
> the same code base.

There aren't many backend changes not tied to other code that can't
be contributed, such as Motorola's AltiVec support.  But you're
right, we've been falling behind in contributing local changes.
Spending too much time arguing about controversial changes I guess... :-)

Stan

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

[Aldy Hernandez]

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

 > How could we go about step 3?  I'm sure there are a million ways,
 > but let me illustrate one possible scenario (for AltiVec):
 >    1. We create a file called gcc/config/rs6000/c-parse.in.diff
 >       (and something analogous for C++)
 >    2. At build time, this diff will be used to patch up
 >       gcc/c-parse.in if needed.

This is a neat hack, but someone will still have to maintain a
separate set of patches for altivec stuff, which is what i'm trying to
avoid.

If we do the __vector stuff and come up with a generic way applicable
to all SIMD architectures, then we a) improve gcc b) do not cause a
maintenance nightmare.

It might be eaiser for Apple to keep separate trees because you only
support one target, and don't contribute your code as often as we do.

Be that as it may, even if we implement __vector correctly, we still
need patches for vector constant initializers, because there is just
no way in hell the following is going to be accepted:

        vector int foo = ((vector int)(1,2,3,4));

I assume we will add extensions with { }'s that will be incorporated
into gcc, but then have additional patches for ()'s that will never be
incorporated.

 >    2. It will be the sole responsibility of the users of AltiVec
 >       extensions to maintain the diff so that it can be applied
 >       cleanly; mainline developers need not and SHOULD NOT be
 >       forced to deal with this.

Let's try to try to come up with a generic solution, and then use your
approach for whatever we know will NEVER make it into mainline gcc.

 >> the world?  Ironically, this extension makes our internal version of
 >> GCC more complicated and time-consuming to merge with FSF sources, so
 >> our imports take longer and have more problems, which means that your
 >> own daily work today has been made more difficult by the expedient
 >> choice of several years ago.

 > True, but I suspect that we (i.e., Apple) are far from the only ones
 > in this situation, which is why it is so desirable, IMHO, to be
 > able to put all such target-specific stuff in the FSF tree to begin
 > with!  Of course, we already do this for back-end/codegen stuff -- we
 > just need to generalize this model.

It would be really nice if you guys contributed your internal changes
on a more regular basis.  Stan tells me there lots of Darwin
optimizations in the backend that you guys haven't contributed.  It's
just easier to get a better overall picture if we're all looking at
the same code base.

Aldy

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

[Bernd Schmidt]

On Tue, 27 Nov 2001, Ziemowit Laski wrote:

> How could we go about step 3?  I'm sure there are a million ways,
> but let me illustrate one possible scenario (for AltiVec):
>    1. We create a file called gcc/config/rs6000/c-parse.in.diff
>       (and something analogous for C++)
>    2. At build time, this diff will be used to patch up
>       gcc/c-parse.in if needed.

When you suggest that there is no harm in that, you think only of the
present, not of the future.

Well, imagine we try to support not one, but fourty-two poorly designed
extensions this way (and it would happen - everyone would go "hey, you
did it for Altivec, why can't I put in my feature too").  Imagine trying
to make any changes to the C parser if you have to make sure none of these
patches break.  It would be impossible - you'd have to build and test as
many toolchains as there are such extensions, rather than building just
one.

Conditional compilation has the same problem.  It's a maintenance
nightmare.  The only way to prevent it is to say "no" right at the
start.


Bernd

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

[Ziemowit Laski]

On Tuesday, November 27, 2001, at 02:13 , Bernd Schmidt wrote:

> Well, imagine we try to support not one, but fourty-two poorly designed
> extensions this way (and it would happen - everyone would go "hey, you
> did it for Altivec, why can't I put in my feature too").  Imagine trying
> to make any changes to the C parser if you have to make sure none of 
> these
> patches break.

No -- YOU DON'T have to make sure these patches don't break.  THAT is the
responsibility solely of the authors/users of the patch in question.

And yes, I would absolutely allow forty-two poorly designed extensions
to cohabit with the mainline compiler in this way. :)

--Zem
--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085

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

[Bernd Schmidt]

On Tue, 27 Nov 2001, Ziemowit Laski wrote:

> On Tuesday, November 27, 2001, at 02:13 , Bernd Schmidt wrote:
> 
> > Well, imagine we try to support not one, but fourty-two poorly designed
> > extensions this way (and it would happen - everyone would go "hey, you
> > did it for Altivec, why can't I put in my feature too").  Imagine trying
> > to make any changes to the C parser if you have to make sure none of 
> > these
> > patches break.
> 
> No -- YOU DON'T have to make sure these patches don't break.  THAT is the
> responsibility solely of the authors/users of the patch in question.

It sounded like you suggested the patch would be applied automatically
during the build.  In that case, the patch would have to be uptodate to
prevent a build failure.

If it isn't applied automatically and requires user intervention, you
could just as well distribute it separately from gcc.

> And yes, I would absolutely allow forty-two poorly designed extensions
> to cohabit with the mainline compiler in this way. :)

If you don't make it the C frontend maintainer's responsibility to keep
them working, you'll end up with fourty-two non-working extensions pretty
quick.


Bernd

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

[Ziemowit Laski]

On Tuesday, November 27, 2001, at 02:40 , Bernd Schmidt wrote:

>> No -- YOU DON'T have to make sure these patches don't break.  THAT is 
>> the
>> responsibility solely of the authors/users of the patch in question.
>
> It sounded like you suggested the patch would be applied automatically
> during the build.  In that case, the patch would have to be uptodate to
> prevent a build failure.

The patch could be applied either (1) automatically for certain target
triplets or (2) only when an explicit flag is passed to 'configure'.
(Come to think of it, the latter is preferrable since it makes the
whole process explicit).  But the bottom line is: extension user
beware! :)

> If you don't make it the C frontend maintainer's responsibility to keep
> them working, you'll end up with fourty-two non-working extensions 
> pretty
> quick.

To which I say -- fine!  (At the same time, I realize it is precisely
this that most of you are objecting to :) :) )

If you have a non-working extension, it simply means it has fallen into
disuse (you could even nuke it out of the tree if you want).  And as
long as there are users, they will have to see to it that it is
maintained.

--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085

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

[Ziemowit Laski]

On Tuesday, November 27, 2001, at 02:40 , Bernd Schmidt wrote:

>> No -- YOU DON'T have to make sure these patches don't break.  THAT is 
>> the
>> responsibility solely of the authors/users of the patch in question.
>
> It sounded like you suggested the patch would be applied automatically
> during the build.  In that case, the patch would have to be uptodate to
> prevent a build failure.

The patch could be applied either (1) automatically for certain target
triplets or (2) only when an explicit flag is passed to 'configure'.
(Come to think of it, the latter is preferrable since it makes the
whole process explicit).  But the bottom line is: extension user
beware! :)

> If you don't make it the C frontend maintainer's responsibility to keep
> them working, you'll end up with fourty-two non-working extensions 
> pretty
> quick.

To which I say -- fine!  (At the same time, I realize it is precisely
this that most of you are objecting to :) :) )

If you have a non-working extension, it simply means it has fallen into
disuse (you could even nuke it out of the tree if you want).  And as
long as there are users, they will have to see to it that it is
maintained.

--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085

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

[Bernd Schmidt]

On Tue, 27 Nov 2001, Ziemowit Laski wrote:

> On Tuesday, November 27, 2001, at 02:13 , Bernd Schmidt wrote:
> 
> > Well, imagine we try to support not one, but fourty-two poorly designed
> > extensions this way (and it would happen - everyone would go "hey, you
> > did it for Altivec, why can't I put in my feature too").  Imagine trying
> > to make any changes to the C parser if you have to make sure none of 
> > these
> > patches break.
> 
> No -- YOU DON'T have to make sure these patches don't break.  THAT is the
> responsibility solely of the authors/users of the patch in question.

It sounded like you suggested the patch would be applied automatically
during the build.  In that case, the patch would have to be uptodate to
prevent a build failure.

If it isn't applied automatically and requires user intervention, you
could just as well distribute it separately from gcc.

> And yes, I would absolutely allow forty-two poorly designed extensions
> to cohabit with the mainline compiler in this way. :)

If you don't make it the C frontend maintainer's responsibility to keep
them working, you'll end up with fourty-two non-working extensions pretty
quick.


Bernd

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

[Ziemowit Laski]

On Tuesday, November 27, 2001, at 02:13 , Bernd Schmidt wrote:

> Well, imagine we try to support not one, but fourty-two poorly designed
> extensions this way (and it would happen - everyone would go "hey, you
> did it for Altivec, why can't I put in my feature too").  Imagine trying
> to make any changes to the C parser if you have to make sure none of 
> these
> patches break.

No -- YOU DON'T have to make sure these patches don't break.  THAT is the
responsibility solely of the authors/users of the patch in question.

And yes, I would absolutely allow forty-two poorly designed extensions
to cohabit with the mainline compiler in this way. :)

--Zem
--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085

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

[Bernd Schmidt]

On Tue, 27 Nov 2001, Ziemowit Laski wrote:

> How could we go about step 3?  I'm sure there are a million ways,
> but let me illustrate one possible scenario (for AltiVec):
>    1. We create a file called gcc/config/rs6000/c-parse.in.diff
>       (and something analogous for C++)
>    2. At build time, this diff will be used to patch up
>       gcc/c-parse.in if needed.

When you suggest that there is no harm in that, you think only of the
present, not of the future.

Well, imagine we try to support not one, but fourty-two poorly designed
extensions this way (and it would happen - everyone would go "hey, you
did it for Altivec, why can't I put in my feature too").  Imagine trying
to make any changes to the C parser if you have to make sure none of these
patches break.  It would be impossible - you'd have to build and test as
many toolchains as there are such extensions, rather than building just
one.

Conditional compilation has the same problem.  It's a maintenance
nightmare.  The only way to prevent it is to say "no" right at the
start.


Bernd

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

[Stan Shebs]

Ziemowit Laski wrote:
> 
> My point (or, perhaps, points) were:
>    1. GCC is used on a variety of real-world platforms
>    2. In that same real world, people have invented tons of
>       target-specific extensions to C and C++ to get extra mileage
>       out of their particular hardware/OS setup.
>    3. Ergo, we should be able to come up with a 'configure'-based
>       mechanism for enabling selected extensions for selected target
>       WHILE LEAVING THEM HIDDEN FROM MAINLINE USERS.

You're right; we certainly can.  But should we?  GCC has built up
a huge user base without support for arbitrary frontend extensions.
If the extensions were so important, we would see messages about them
every week on this list, but historically there have been very few
requests.  In fact, AltiVec is by far the largest and most complex
target-specific extension I know of, and even then the world total
amount of AltiVec-extension-using code is maybe several thousand
lines of C.  If there are more important or widespread extensions
that GCC ought to support, now would be a good time to list them.

> How could we go about step 3?  I'm sure there are a million ways,
> but let me illustrate one possible scenario (for AltiVec):
>    1. We create a file called gcc/config/rs6000/c-parse.in.diff
>       (and something analogous for C++)
>    2. At build time, this diff will be used to patch up
>       gcc/c-parse.in if needed.

An interesting idea, but how is it different from Apple or whoever
maintaining a locally-modified version?  If c-parse.in changes,
then the diff will likely be broken, and since you're saying it's
not the responsibility of the C frontend maintainer to keep the
c-parse.in.diff working, the AltiVec maintainer has to step in
and rework the diff to make it useful again - which is exactly
what one of us does when we import FSF sources.

Part of my concern with a mechanism to support arbitrary change
is that the consequences are unpredictably broad.  AltiVec-style
vector constants, for instance, entail not only the syntactic
extension, but also a new tree node type, and additional code
throughout the compiler.

Stan

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

[Ziemowit Laski]

On Tuesday, November 27, 2001, at 02:20 , Stan Shebs wrote:

> Ziemowit Laski wrote:
>>
>> My point (or, perhaps, points) were:
>>    1. GCC is used on a variety of real-world platforms
>>    2. In that same real world, people have invented tons of
>>       target-specific extensions to C and C++ to get extra mileage
>>       out of their particular hardware/OS setup.
>>    3. Ergo, we should be able to come up with a 'configure'-based
>>       mechanism for enabling selected extensions for selected target
>>       WHILE LEAVING THEM HIDDEN FROM MAINLINE USERS.
>
> You're right; we certainly can.  But should we?  GCC has built up
> a huge user base without support for arbitrary frontend extensions.
> If the extensions were so important, we would see messages about them
> every week on this list, but historically there have been very few
> requests.  In fact, AltiVec is by far the largest and most complex
> target-specific extension I know of, and even then the world total
> amount of AltiVec-extension-using code is maybe several thousand
> lines of C.  If there are more important or widespread extensions
> that GCC ought to support, now would be a good time to list them.

Very true -- speak up, people! :) :)
>
>> How could we go about step 3?  I'm sure there are a million ways,
>> but let me illustrate one possible scenario (for AltiVec):
>>    1. We create a file called gcc/config/rs6000/c-parse.in.diff
>>       (and something analogous for C++)
>>    2. At build time, this diff will be used to patch up
>>       gcc/c-parse.in if needed.
>
> An interesting idea, but how is it different from Apple or whoever
> maintaining a locally-modified version?  If c-parse.in changes,
> then the diff will likely be broken, and since you're saying it's
> not the responsibility of the C frontend maintainer to keep the
> c-parse.in.diff working, the AltiVec maintainer has to step in
> and rework the diff to make it useful again - which is exactly
> what one of us does when we import FSF sources.

Yes, you'll need to fix up c-parse.in.diff, but you WOULDN'T
HAVE TO DO THE IMPORT IN THE FIRST PLACE! :) :) :)

> Part of my concern with a mechanism to support arbitrary change
> is that the consequences are unpredictably broad.  AltiVec-style
> vector constants, for instance, entail not only the syntactic
> extension, but also a new tree node type, and additional code
> throughout the compiler.

Of course -- and GCC already provides a place for the back-end
portion of this code -- the config/ folders.  All I'm trying to
do is find a warm, friendly place for the front-end portion. :)

--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085

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

[Ziemowit Laski]

On Tuesday, November 27, 2001, at 02:20 , Stan Shebs wrote:

> Ziemowit Laski wrote:
>>
>> My point (or, perhaps, points) were:
>>    1. GCC is used on a variety of real-world platforms
>>    2. In that same real world, people have invented tons of
>>       target-specific extensions to C and C++ to get extra mileage
>>       out of their particular hardware/OS setup.
>>    3. Ergo, we should be able to come up with a 'configure'-based
>>       mechanism for enabling selected extensions for selected target
>>       WHILE LEAVING THEM HIDDEN FROM MAINLINE USERS.
>
> You're right; we certainly can.  But should we?  GCC has built up
> a huge user base without support for arbitrary frontend extensions.
> If the extensions were so important, we would see messages about them
> every week on this list, but historically there have been very few
> requests.  In fact, AltiVec is by far the largest and most complex
> target-specific extension I know of, and even then the world total
> amount of AltiVec-extension-using code is maybe several thousand
> lines of C.  If there are more important or widespread extensions
> that GCC ought to support, now would be a good time to list them.

Very true -- speak up, people! :) :)
>
>> How could we go about step 3?  I'm sure there are a million ways,
>> but let me illustrate one possible scenario (for AltiVec):
>>    1. We create a file called gcc/config/rs6000/c-parse.in.diff
>>       (and something analogous for C++)
>>    2. At build time, this diff will be used to patch up
>>       gcc/c-parse.in if needed.
>
> An interesting idea, but how is it different from Apple or whoever
> maintaining a locally-modified version?  If c-parse.in changes,
> then the diff will likely be broken, and since you're saying it's
> not the responsibility of the C frontend maintainer to keep the
> c-parse.in.diff working, the AltiVec maintainer has to step in
> and rework the diff to make it useful again - which is exactly
> what one of us does when we import FSF sources.

Yes, you'll need to fix up c-parse.in.diff, but you WOULDN'T
HAVE TO DO THE IMPORT IN THE FIRST PLACE! :) :) :)

> Part of my concern with a mechanism to support arbitrary change
> is that the consequences are unpredictably broad.  AltiVec-style
> vector constants, for instance, entail not only the syntactic
> extension, but also a new tree node type, and additional code
> throughout the compiler.

Of course -- and GCC already provides a place for the back-end
portion of this code -- the config/ folders.  All I'm trying to
do is find a warm, friendly place for the front-end portion. :)

--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085

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

[Stan Shebs]

Ziemowit Laski wrote:
> 
> My point (or, perhaps, points) were:
>    1. GCC is used on a variety of real-world platforms
>    2. In that same real world, people have invented tons of
>       target-specific extensions to C and C++ to get extra mileage
>       out of their particular hardware/OS setup.
>    3. Ergo, we should be able to come up with a 'configure'-based
>       mechanism for enabling selected extensions for selected target
>       WHILE LEAVING THEM HIDDEN FROM MAINLINE USERS.

You're right; we certainly can.  But should we?  GCC has built up
a huge user base without support for arbitrary frontend extensions.
If the extensions were so important, we would see messages about them
every week on this list, but historically there have been very few
requests.  In fact, AltiVec is by far the largest and most complex
target-specific extension I know of, and even then the world total
amount of AltiVec-extension-using code is maybe several thousand
lines of C.  If there are more important or widespread extensions
that GCC ought to support, now would be a good time to list them.

> How could we go about step 3?  I'm sure there are a million ways,
> but let me illustrate one possible scenario (for AltiVec):
>    1. We create a file called gcc/config/rs6000/c-parse.in.diff
>       (and something analogous for C++)
>    2. At build time, this diff will be used to patch up
>       gcc/c-parse.in if needed.

An interesting idea, but how is it different from Apple or whoever
maintaining a locally-modified version?  If c-parse.in changes,
then the diff will likely be broken, and since you're saying it's
not the responsibility of the C frontend maintainer to keep the
c-parse.in.diff working, the AltiVec maintainer has to step in
and rework the diff to make it useful again - which is exactly
what one of us does when we import FSF sources.

Part of my concern with a mechanism to support arbitrary change
is that the consequences are unpredictably broad.  AltiVec-style
vector constants, for instance, entail not only the syntactic
extension, but also a new tree node type, and additional code
throughout the compiler.

Stan

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

[Ziemowit Laski]

On Tuesday, November 27, 2001, at 09:47 , Stan Shebs wrote:

> I wasn't going to mention your name, but if you want to take
> credit I can't stop you... :-)

I likewise held my peace, but now that the cat is out of the bag... :) :)
>
>> For MrC[pp] is was easy to do.  And it was based on
>> feedback from our internal (Apple) AltiVec users (the *only* users at
>> that time other than Moto).  They didn't want to write __vector and
>> they certainly couldn't tolerate "vector" being a macro that expanded
>> to __vector (which Moto was proposing).  And "vector" couldn't be
>> treated as an unconditional reserved word either.
>
> Nevertheless, I still think it was a mistake.  When it comes to
> messing with the language, we often need to say "no" to users, who

I agree that Ira's 'vector' (as opposed to '__vector') was not the
cleanest way to approach this (although not nearly as nefarious as
'#pragma poison'), but THIS IS TOTALLY BESIDE THE POINT!

My point (or, perhaps, points) were:
   1. GCC is used on a variety of real-world platforms
   2. In that same real world, people have invented tons of
      target-specific extensions to C and C++ to get extra mileage
      out of their particular hardware/OS setup.
   3. Ergo, we should be able to come up with a 'configure'-based
      mechanism for enabling selected extensions for selected target
      WHILE LEAVING THEM HIDDEN FROM MAINLINE USERS.

How could we go about step 3?  I'm sure there are a million ways,
but let me illustrate one possible scenario (for AltiVec):
   1. We create a file called gcc/config/rs6000/c-parse.in.diff
      (and something analogous for C++)
   2. At build time, this diff will be used to patch up
      gcc/c-parse.in if needed.

The foregoing approach has two immediate consequences:
   1. The mainline grammar/lexical analyzer remains unchanged
   2. It will be the sole responsibility of the users of AltiVec
      extensions to maintain the diff so that it can be applied
      cleanly; mainline developers need not and SHOULD NOT be
      forced to deal with this.

> the world?  Ironically, this extension makes our internal version of
> GCC more complicated and time-consuming to merge with FSF sources, so
> our imports take longer and have more problems, which means that your
> own daily work today has been made more difficult by the expedient
> choice of several years ago.

True, but I suspect that we (i.e., Apple) are far from the only ones
in this situation, which is why it is so desirable, IMHO, to be
able to put all such target-specific stuff in the FSF tree to begin
with!  Of course, we already do this for back-end/codegen stuff -- we
just need to generalize this model.

--Zem
--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085

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

[Stan Shebs]

Ira Ruben wrote:
> 
> >There were some real boners,
> >such as the context sensitivity of the vector keyword, that I think
> >could have been avoided if some GCC folks had participated.
> 
> At the time the AltiVec language model was being designed gcc was
> never in the picture -- period!  The only "players" were MrC[pp] and
> Moto's Mcc (not even MW).  I'm not sure what prompted Moto to try to
> later retrofit the design into gcc.

Easy - Motorola wasn't going to be able to sell G4s to either
Linux or embedded users (VxWorks etc) without having AltiVec
support in GCC.  It speaks volumes that nobody at Motorola seemed
to be aware that GCC was Wind River's standard compiler, and
that it thus might be a good idea to talk to GCC people about the
proposed extension.

> And I don't consider the use of
> "vector" as a context-sensitive keyword a "real boner".  THAT WAS MY
> DECISION/DESIGN!

I wasn't going to mention your name, but if you want to take
credit I can't stop you... :-)

> For MrC[pp] is was easy to do.  And it was based on
> feedback from our internal (Apple) AltiVec users (the *only* users at
> that time other than Moto).  They didn't want to write __vector and
> they certainly couldn't tolerate "vector" being a macro that expanded
> to __vector (which Moto was proposing).  And "vector" couldn't be
> treated as an unconditional reserved word either.

Nevertheless, I still think it was a mistake.  When it comes to
messing with the language, we often need to say "no" to users, who
typically don't understand the consequences of tinkering with language
syntax and semantics - indeed, they're paying us to be the experts.
While it may have been easy to do in MrC, did anybody consider that
the extension was going to affect every other PowerPC compiler in
the world?  Ironically, this extension makes our internal version of
GCC more complicated and time-consuming to merge with FSF sources, so
our imports take longer and have more problems, which means that your
own daily work today has been made more difficult by the expedient
choice of several years ago.

Stan

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

[Stan Shebs]

Ziemowit Laski wrote:
> 
> But this brings up a more general question, one that I've been meaning to
> ask of the wider community for quite some time: Should we come up with a
> generalized architecture in GCC (for all front-ends) to enable front-end
> extensions:
>    1) only for specific platforms (e.g., Altivec for PPC targets,
> 'dllexport'
>       for Windows, etc.); and/or
>    2) only when explicitly specified via the configure script (e.g.,
>       '--enable-altivec-keywords', '--enable-pascal-strings')

When you put it that way, my general reaction is to say "bleah". :-)

GCC philosophy has never been to implement every feature ever seen
in somebody else's compiler, but instead to have a single compiler
that behaves consistently across a range of architectures and
operating systems.  There are frontend extension mechanisms, such
as pragmas and attributes for C dialects for instance, as well as
builtin functions, so there is plenty to work with already.  It
may be that these are inadequate, but the case would have to
be pretty compelling on technical grounds.

For instance, in the case of AltiVec extensions, the effect of
vector/pixel keywords can be almost entirely achieved with mode
attributes, the overloaded builtins could be handled by adding
a general concept of overloaded builtins, leaving only the vector
constant syntax as an oddball.  From what I know of the AltiVec-
using population, the total aggregate effort of changing the
syntax of all the vector constants in source code might add up
to as much as one day - less than the effort needed to get the
extension working in GCC.  So should we implement the extension
and support it forever, or get users to spend a few minutes to
change their sources?

The moral of the story with respect to AltiVec is that GNU people
should try to be more involved when new technologies are being
introduced.  As far as I know (I admit to being out of the loop
myself), the AltiVec programming model was designed by a group
working on various proprietary compilers, and the question of GCC
support didn't come up until later.  There were some real boners,
such as the context sensitivity of the vector keyword, that I think
could have been avoided if some GCC folks had participated.

It's easy to say "oh, I can't do anything without having a signed
contract first" or "why should I care about PowerPC/x86/ARM/etc",
but in cases like these some upfront interest and nosiness will
pay off in the long run; we can then spend our development time on
improvements that benefit everybody, rather than tricky hacks to
support another limited-interest target-specific extension.

Stan

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

[Ziemowit Laski]

On Monday, November 26, 2001, at 03:45 , Joseph S. Myers wrote:

> On 26 Nov 2001, Aldy Hernandez wrote:
>
>> the altivec specs require changes to the gcc front end.  this has been
>> brought up before but no one has really commented.  now before everyone
>> start raising shields and going "yuck, no way", hear me out.

Unfortunately, AltiVec extensions are (syntactically) quite yucky.  
Legacy
Motorola/Apple/IBM code is likely to rely not only on '__vector' and 
'__pixel'
and 'bool' (in its non-C++ sense!) but also 'vector', 'pixel' and even 
'__bool'!
If I had my druthers, I'd just stick to the '__attribute__(...)' 
notation, but
obviously I don't have my druthers. :(  At any rate, AltiVec syntax is 
not
easy to "intellectually reconcile" with any of the underlying 
languages.  (And
yes, we do have it in our Apple gcc3 tree...)

But this brings up a more general question, one that I've been meaning to
ask of the wider community for quite some time: Should we come up with a
generalized architecture in GCC (for all front-ends) to enable front-end
extensions:
   1) only for specific platforms (e.g., Altivec for PPC targets, 
'dllexport'
      for Windows, etc.); and/or
   2) only when explicitly specified via the configure script (e.g.,
      '--enable-altivec-keywords', '--enable-pascal-strings')

AltiVec is merely one example of an idiosyncratic extension that exists 
on
only a small fraction of targets that GCC supports.  It would be nice to
only enable the extension for the targets that need it, analogously to
how back-end bits are pulled in from gcc/config/....  Naturally, it
would also be up to the maintainer(s) of a particular target to ensure
that the front-end extensions continue to work with the main (generic)
front-end.

Anyway, this is just a thought.  I'd be curious as to what the rest of 
you
think about this.

--Zem
--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085