front end changes for altivec

front end changes for altivec

[Aldy Hernandez]

hi guys!

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.

i would really hate to perpetually maintain a set of front end patches,
so i'm wondering if there's any sensible, least intrusive way to
implement these changes and have them incorporated into mainline gcc.

i am not a fan at all of these front end changes, but the specs are
already out there and a variety of other compilers already conform to
them.

the changes are very few and are outlined below:

    __vector keyword:
    
    	__vector int	=> mode(V4SI)
    	__vector char	=> mode(V16QI)
    	etc etc
    	
        (it could really be __altivec_vector for all i care because the
        specs allow part of the definitions to be in a separate include
        file (altivec.h?), so we could have
        
        #define __vector __altivec_vector
        
	   ...in a separate file.
    
    vector constant initializers:
    
    	__vector int foo = (5, 8, 3, 2);
    
    (yes, those are parentheses, not curlys :-()
    
i'd first like to discuss the feasability of incorporating these changes
with irritating the least amount of people, and having them accepted.

failing this, i have a few thoughts on extending the lexical analyzer to
include some sort of front end plugin support.-- but i'd like to discuss
the previous option first.

bomb away.

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

Re: front end changes for altivec

[Andreas Jaeger]

Aldy Hernandez <aldyh@redhat.com> writes:

> hi guys!
>
> 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.
>
> i would really hate to perpetually maintain a set of front end patches,
> so i'm wondering if there's any sensible, least intrusive way to
> implement these changes and have them incorporated into mainline gcc.
>
> i am not a fan at all of these front end changes, but the specs are
> already out there and a variety of other compilers already conform to
> them.
>
> the changes are very few and are outlined below:
>
>     __vector keyword:
>     
>     	__vector int	=> mode(V4SI)
>     	__vector char	=> mode(V16QI)
>     	etc etc
>     	
>         (it could really be __altivec_vector for all i care because the
>         specs allow part of the definitions to be in a separate include
>         file (altivec.h?), so we could have
>         
>         #define __vector __altivec_vector
>         
> 	   ...in a separate file.
>     
>     vector constant initializers:
>     
>     	__vector int foo = (5, 8, 3, 2);
>     
>     (yes, those are parentheses, not curlys :-()
>     
> i'd first like to discuss the feasability of incorporating these changes
> with irritating the least amount of people, and having them accepted.
>
> failing this, i have a few thoughts on extending the lexical analyzer to
> include some sort of front end plugin support.-- but i'd like to discuss
> the previous option first.

How does this relate to Intel's SSE/SSE2?  Could the same frontend
used for all these SIMD extensions?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: front end changes for altivec

[Andreas Jaeger]

Aldy Hernandez <aldyh@redhat.com> writes:

> hi guys!
>
> 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.
>
> i would really hate to perpetually maintain a set of front end patches,
> so i'm wondering if there's any sensible, least intrusive way to
> implement these changes and have them incorporated into mainline gcc.
>
> i am not a fan at all of these front end changes, but the specs are
> already out there and a variety of other compilers already conform to
> them.
>
> the changes are very few and are outlined below:
>
>     __vector keyword:
>     
>     	__vector int	=> mode(V4SI)
>     	__vector char	=> mode(V16QI)
>     	etc etc
>     	
>         (it could really be __altivec_vector for all i care because the
>         specs allow part of the definitions to be in a separate include
>         file (altivec.h?), so we could have
>         
>         #define __vector __altivec_vector
>         
> 	   ...in a separate file.
>     
>     vector constant initializers:
>     
>     	__vector int foo = (5, 8, 3, 2);
>     
>     (yes, those are parentheses, not curlys :-()
>     
> i'd first like to discuss the feasability of incorporating these changes
> with irritating the least amount of people, and having them accepted.
>
> failing this, i have a few thoughts on extending the lexical analyzer to
> include some sort of front end plugin support.-- but i'd like to discuss
> the previous option first.

How does this relate to Intel's SSE/SSE2?  Could the same frontend
used for all these SIMD extensions?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

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

Re: front end changes for altivec

[Aldy Hernandez]

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

i believe it can only be used with signed, unsigned, int, short, float,
and char.  you can't use it with typedefs or enums.

> can't be used with typedefs, structs or unions.  Can it be used with

but they can be used as fields in a struct.

> enums?  Why those particular sizes of vectors rather than others?  Will
> __vector on its own imply __vector int?

__vector must be first among type specifiers.  the specs are rather skekchy,
but it seems like you need to specifically mention int.  you can also
have pointers to these types (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

ok, but how would we differentiate between the diff vector sizes.
altivec has "vector int" being V4SI, but vector int could mean V2SI in
mmx.  suggestion welcome while i think through this.

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

correct.  you can't convert between any of the vector types.  the following
just does a straight copy, no conversion (nop):

  vector short b;
  vector int a = (vector int) b;

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

oh sorry, it has to be casted and it has to have an extra set of ()'s so
it might not be too bad:

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

this kinda sucks all together because i don't think gcc has vector constants
at all, do we?  we could pass it as a BLKmode or as a struct right?

this might not be too bad if we come up with a mechanism for all simd 
processors.  i'm still wondering how to manage the diff sizes.

does this make it clearer?

aldy

Re: front end changes for altivec

[Joseph S. Myers]

On Mon, 26 Nov 2001, Aldy Hernandez wrote:

> __vector must be first among type specifiers.  the specs are rather skekchy,

That's not consistent with how other type specifiers work.  It would make
more sense for the list of possible type specifier combinations to include
such things as "__vector signed int" and any permutation thereof.

> ok, but how would we differentiate between the diff vector sizes.
> altivec has "vector int" being V4SI, but vector int could mean V2SI in
> mmx.  suggestion welcome while i think through this.

The answer from some quarters might be "vector int<4>" or "vector<4> int",
but this adds complications to the C grammar I don't really want there
since > can be part of a constant expression (so if going that way then do
as many as possible of defining disambiguating rules by reference to
existing practice, proving the existence or nonexistence of ambiguous
cases, describing how the parsing should be implemented).  Or use
"vector(4)".  Or add some other way of specifying a non-default vector
size.

> correct.  you can't convert between any of the vector types.  the following
> just does a straight copy, no conversion (nop):
> 
>   vector short b;
>   vector int a = (vector int) b;

What about other operations, e.g. arithmetic?

> 	vector int foo = ((vector int)(1,2,3,4));
> 
> this kinda sucks all together because i don't think gcc has vector constants
> at all, do we?  we could pass it as a BLKmode or as a struct right?

I think you should just use the C99 compound literal syntax here (with
braces, not parentheses).  Presumably the ABI says how such arguments are
passed.

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

Re: front end changes for altivec

[Aldy Hernandez]

On Tue, Nov 27, 2001 at 01:04:05AM +0000, Joseph S. Myers wrote:
> On Mon, 26 Nov 2001, Aldy Hernandez wrote:
> 
> > __vector must be first among type specifiers.  the specs are rather skekchy,
> 
> That's not consistent with how other type specifiers work.  It would make
> more sense for the list of possible type specifier combinations to include
> such things as "__vector signed int" and any permutation thereof.

sure

> > ok, but how would we differentiate between the diff vector sizes.
> > altivec has "vector int" being V4SI, but vector int could mean V2SI in
> > mmx.  suggestion welcome while i think through this.
> 
> The answer from some quarters might be "vector int<4>" or "vector<4> int",
> but this adds complications to the C grammar I don't really want there

i don't link this idea.

> as many as possible of defining disambiguating rules by reference to
> existing practice, proving the existence or nonexistence of ambiguous
> cases, describing how the parsing should be implemented).  Or use

i'm not sure i follow., can you give an example.

> "vector(4)".  Or add some other way of specifying a non-default vector
> size.

that could be better. 
> 
> > correct.  you can't convert between any of the vector types.  the following
> > just does a straight copy, no conversion (nop):
> > 
> >   vector short b;
> >   vector int a = (vector int) b;
> 
> What about other operations, e.g. arithmetic?

not allowed. or perhaps undefined


> > 	vector int foo = ((vector int)(1,2,3,4));
> > 
> > this kinda sucks all together because i don't think gcc has vector constants
> > at all, do we?  we could pass it as a BLKmode or as a struct right?
> 
> I think you should just use the C99 compound literal syntax here (with

yes, ideally.  but what do we do for the current specs which specifies
parentheses?

aldy

Re: front end changes for altivec

[Richard Henderson]

On Mon, Nov 26, 2001 at 05:50:04PM -0800, Aldy Hernandez wrote:
> yes, ideally.  but what do we do for the current specs which specifies
> parentheses?

Ignore them.


r~

Re: front end changes for altivec

[Richard Henderson]

On Mon, Nov 26, 2001 at 05:50:04PM -0800, Aldy Hernandez wrote:
> yes, ideally.  but what do we do for the current specs which specifies
> parentheses?

Ignore them.


r~

Re: front end changes for altivec

[Aldy Hernandez]

On Tue, Nov 27, 2001 at 01:04:05AM +0000, Joseph S. Myers wrote:
> On Mon, 26 Nov 2001, Aldy Hernandez wrote:
> 
> > __vector must be first among type specifiers.  the specs are rather skekchy,
> 
> That's not consistent with how other type specifiers work.  It would make
> more sense for the list of possible type specifier combinations to include
> such things as "__vector signed int" and any permutation thereof.

sure

> > ok, but how would we differentiate between the diff vector sizes.
> > altivec has "vector int" being V4SI, but vector int could mean V2SI in
> > mmx.  suggestion welcome while i think through this.
> 
> The answer from some quarters might be "vector int<4>" or "vector<4> int",
> but this adds complications to the C grammar I don't really want there

i don't link this idea.

> as many as possible of defining disambiguating rules by reference to
> existing practice, proving the existence or nonexistence of ambiguous
> cases, describing how the parsing should be implemented).  Or use

i'm not sure i follow., can you give an example.

> "vector(4)".  Or add some other way of specifying a non-default vector
> size.

that could be better. 
> 
> > correct.  you can't convert between any of the vector types.  the following
> > just does a straight copy, no conversion (nop):
> > 
> >   vector short b;
> >   vector int a = (vector int) b;
> 
> What about other operations, e.g. arithmetic?

not allowed. or perhaps undefined


> > 	vector int foo = ((vector int)(1,2,3,4));
> > 
> > this kinda sucks all together because i don't think gcc has vector constants
> > at all, do we?  we could pass it as a BLKmode or as a struct right?
> 
> I think you should just use the C99 compound literal syntax here (with

yes, ideally.  but what do we do for the current specs which specifies
parentheses?

aldy

Re: front end changes for altivec

[Aldy Hernandez]

> The answer from some quarters might be "vector int<4>" or "vector<4> int",
> but this adds complications to the C grammar I don't really want there
> since > can be part of a constant expression (so if going that way then do
> as many as possible of defining disambiguating rules by reference to
> existing practice, proving the existence or nonexistence of ambiguous
> cases, describing how the parsing should be implemented).  Or use
> "vector(4)".  Or add some other way of specifying a non-default vector

i've thought about this some more.

do we really need to specify a vector size?  simd architectures
generally have a specific vector size, 64bits for sse* and 128bits for
altivec.  

so, "vector int x" in sse* means V2SI, provided ints are 32bits.

in altivec, "vector int" means V4SI, provided ints are 32bits.

so do we _really_ need to specify a size or can it be determined from
backend info?

if we really do need to specify vector size, then either of your
proposals will work:

	vector(4) int foo;
	vector<4> int foo;

(i really don't like "vector int<4> foo" :))

what do you suggest <> or ()?

furthermore, we need to have a default vector size for the altivec stuff
to work-- and it makes for prettier code :).  so:

	vector int foo	--> V4SI in altivec
	vector int foo	--> V2SI in SSE*
	etc

we would need defaults for vector + [int, short, bool, char, float]. 
for this, we could add a macro to gcc that given an SI/HI/QI/SF returns
an V4SI/V8HI/V18QI/V4SF.  this seems like the cleanest idea.

how does this sound?

aldy

Re: front end changes for altivec

[Andreas Jaeger]

Aldy Hernandez <aldyh@cygnus.com> writes:

>> The answer from some quarters might be "vector int<4>" or "vector<4> int",
>> but this adds complications to the C grammar I don't really want there
>> since > can be part of a constant expression (so if going that way then do
>> as many as possible of defining disambiguating rules by reference to
>> existing practice, proving the existence or nonexistence of ambiguous
>> cases, describing how the parsing should be implemented).  Or use
>> "vector(4)".  Or add some other way of specifying a non-default vector
>
> i've thought about this some more.
>
> do we really need to specify a vector size?  simd architectures
> generally have a specific vector size, 64bits for sse* and 128bits for
> altivec.  

SSE is 128 bits.

But I agree, we should find a general solution!

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: front end changes for altivec

[Aldy Hernandez]

On Tue, 2001-11-27 at 09:50, Andreas Jaeger wrote:
> Aldy Hernandez <aldyh@cygnus.com> writes:
> 
> >> The answer from some quarters might be "vector int<4>" or "vector<4> int",
> >> but this adds complications to the C grammar I don't really want there
> >> since > can be part of a constant expression (so if going that way then do
> >> as many as possible of defining disambiguating rules by reference to
> >> existing practice, proving the existence or nonexistence of ambiguous
> >> cases, describing how the parsing should be implemented).  Or use
> >> "vector(4)".  Or add some other way of specifying a non-default vector
> >
> > i've thought about this some more.
> >
> > do we really need to specify a vector size?  simd architectures
> > generally have a specific vector size, 64bits for sse* and 128bits for
> > altivec.  
> 
> SSE is 128 bits.

sorry, mmx then.

which complicates things further... with this mmx and sse and sse2, what
would the default be for "vector int"?  mmx is 64bits (right?) and sse
is 128bits, so when we talk of vector int, what are we talking about.

perhaps i should leave that to whomever adds the vector keyword stuff
for x86 :)

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

Re: front end changes for altivec

[Bernd Schmidt]

On 27 Nov 2001, Aldy Hernandez wrote:

> On Tue, 2001-11-27 at 09:50, Andreas Jaeger wrote:
> > Aldy Hernandez <aldyh@cygnus.com> writes:
> > 
> > >> The answer from some quarters might be "vector int<4>" or "vector<4> int",
> > >> but this adds complications to the C grammar I don't really want there
> > >> since > can be part of a constant expression (so if going that way then do
> > >> as many as possible of defining disambiguating rules by reference to
> > >> existing practice, proving the existence or nonexistence of ambiguous
> > >> cases, describing how the parsing should be implemented).  Or use
> > >> "vector(4)".  Or add some other way of specifying a non-default vector
> > >
> > > i've thought about this some more.
> > >
> > > do we really need to specify a vector size?  simd architectures
> > > generally have a specific vector size, 64bits for sse* and 128bits for
> > > altivec.  
> > 
> > SSE is 128 bits.
> 
> sorry, mmx then.
> 
> which complicates things further... with this mmx and sse and sse2, what
> would the default be for "vector int"?  mmx is 64bits (right?) and sse
> is 128bits, so when we talk of vector int, what are we talking about.

I think all these problems show clearly that the extension is poorly thought
out and should not be included in gcc.


Bernd

Re: front end changes for altivec

[Aldy Hernandez]

> > > SSE is 128 bits.
> > 
> > sorry, mmx then.
> > 
> > which complicates things further... with this mmx and sse and sse2, what
> > would the default be for "vector int"?  mmx is 64bits (right?) and sse
> > is 128bits, so when we talk of vector int, what are we talking about.
> 
> I think all these problems show clearly that the extension is poorly thought
> out and should not be included in gcc.

that's why i brought up here first, so we can talk it through and
hopefully come up with a good design that can be used across all the
different simd architectures.

re the different sizes in x86 simd (mmx/sse/sse2), we could have the
default vector sizes depend on the macro i proposed.  the macro could
return different vector sizes based on TARGET_MMX/etc flags.  very
simple.

and if the user specifies:

	vector<2> int foo;

it can only mean V2SI in mmx if TARGET_MMX (and available) or V2SI in
sse* if TARGET_SSE* (and available).

i don't think it's that bad.

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

Re: front end changes for altivec

[Aldy Hernandez]

> > > SSE is 128 bits.
> > 
> > sorry, mmx then.
> > 
> > which complicates things further... with this mmx and sse and sse2, what
> > would the default be for "vector int"?  mmx is 64bits (right?) and sse
> > is 128bits, so when we talk of vector int, what are we talking about.
> 
> I think all these problems show clearly that the extension is poorly thought
> out and should not be included in gcc.

that's why i brought up here first, so we can talk it through and
hopefully come up with a good design that can be used across all the
different simd architectures.

re the different sizes in x86 simd (mmx/sse/sse2), we could have the
default vector sizes depend on the macro i proposed.  the macro could
return different vector sizes based on TARGET_MMX/etc flags.  very
simple.

and if the user specifies:

	vector<2> int foo;

it can only mean V2SI in mmx if TARGET_MMX (and available) or V2SI in
sse* if TARGET_SSE* (and available).

i don't think it's that bad.

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

Re: front end changes for altivec

[Bernd Schmidt]

On 27 Nov 2001, Aldy Hernandez wrote:

> On Tue, 2001-11-27 at 09:50, Andreas Jaeger wrote:
> > Aldy Hernandez <aldyh@cygnus.com> writes:
> > 
> > >> The answer from some quarters might be "vector int<4>" or "vector<4> int",
> > >> but this adds complications to the C grammar I don't really want there
> > >> since > can be part of a constant expression (so if going that way then do
> > >> as many as possible of defining disambiguating rules by reference to
> > >> existing practice, proving the existence or nonexistence of ambiguous
> > >> cases, describing how the parsing should be implemented).  Or use
> > >> "vector(4)".  Or add some other way of specifying a non-default vector
> > >
> > > i've thought about this some more.
> > >
> > > do we really need to specify a vector size?  simd architectures
> > > generally have a specific vector size, 64bits for sse* and 128bits for
> > > altivec.  
> > 
> > SSE is 128 bits.
> 
> sorry, mmx then.
> 
> which complicates things further... with this mmx and sse and sse2, what
> would the default be for "vector int"?  mmx is 64bits (right?) and sse
> is 128bits, so when we talk of vector int, what are we talking about.

I think all these problems show clearly that the extension is poorly thought
out and should not be included in gcc.


Bernd

Re: front end changes for altivec

[Aldy Hernandez]

On Tue, 2001-11-27 at 09:50, Andreas Jaeger wrote:
> Aldy Hernandez <aldyh@cygnus.com> writes:
> 
> >> The answer from some quarters might be "vector int<4>" or "vector<4> int",
> >> but this adds complications to the C grammar I don't really want there
> >> since > can be part of a constant expression (so if going that way then do
> >> as many as possible of defining disambiguating rules by reference to
> >> existing practice, proving the existence or nonexistence of ambiguous
> >> cases, describing how the parsing should be implemented).  Or use
> >> "vector(4)".  Or add some other way of specifying a non-default vector
> >
> > i've thought about this some more.
> >
> > do we really need to specify a vector size?  simd architectures
> > generally have a specific vector size, 64bits for sse* and 128bits for
> > altivec.  
> 
> SSE is 128 bits.

sorry, mmx then.

which complicates things further... with this mmx and sse and sse2, what
would the default be for "vector int"?  mmx is 64bits (right?) and sse
is 128bits, so when we talk of vector int, what are we talking about.

perhaps i should leave that to whomever adds the vector keyword stuff
for x86 :)

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

Re: front end changes for altivec

[Andreas Jaeger]

Aldy Hernandez <aldyh@cygnus.com> writes:

>> The answer from some quarters might be "vector int<4>" or "vector<4> int",
>> but this adds complications to the C grammar I don't really want there
>> since > can be part of a constant expression (so if going that way then do
>> as many as possible of defining disambiguating rules by reference to
>> existing practice, proving the existence or nonexistence of ambiguous
>> cases, describing how the parsing should be implemented).  Or use
>> "vector(4)".  Or add some other way of specifying a non-default vector
>
> i've thought about this some more.
>
> do we really need to specify a vector size?  simd architectures
> generally have a specific vector size, 64bits for sse* and 128bits for
> altivec.  

SSE is 128 bits.

But I agree, we should find a general solution!

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 09:24:03AM -0600, Aldy Hernandez wrote:
> do we really need to specify a vector size?

Yes.  This documents the intention of the author of the code.

With such, one could write generic code to handle the case that
the machine does not support SIMD at all, or that the machine
supports SIMD but in a narrower mode written in the source.

It also lets the author write code with larger vector sizes (8, 16, 32...)
and have the compiler automatically decompose into whatever the
machine can actually handle.  Which might possibly give the 
compiler more information and let it optimize better.  Dunno
for sure about that, but it's not implausable.

> 	vector(4) int foo;
> 	vector<4> int foo;

I prefer

	int foo __attribute__((vector(4)));

which, iirc, also works as a prefix,

	__attribute__((vector(4))) int foo;

which, with appropriate cpp magic in <altivec.h> becomes

#define __vector  __attribute__((__vector__(4)))

	__vector int foo;

which merely leaves you the c++ nastiness problem with
"vector" vs "__vector" vs "std::vector".


r~

Re: front end changes for altivec

[Aldy Hernandez]

> I prefer
> 
> 	int foo __attribute__((vector(4)));
> 
> which, iirc, also works as a prefix,
> 
> 	__attribute__((vector(4))) int foo;
> 
> which, with appropriate cpp magic in <altivec.h> becomes
> 
> #define __vector  __attribute__((__vector__(4)))
> 
> 	__vector int foo;

not good, because we have "vector int" (V4SI), "vector short" (V8HI),
"vector char" (V16QI), etc.  we can't just define "__vector" to expand
to a given vector size because that depends on the type being vectored.

i still prefer :):

	__vector(4) int foo;

and then have a default for the given backend+target_switches:

	__vector int foo;

a clean implementation IMO.

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

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 03:54:42PM -0600, Aldy Hernandez wrote:
> not good, because we have "vector int" (V4SI), "vector short" (V8HI),
> "vector char" (V16QI), etc.  we can't just define "__vector" to expand
> to a given vector size because that depends on the type being vectored.

How about __vector_size__(16) then?

> and then have a default for the given backend+target_switches...

Absolutely not.  No machine dependant defaults.  You can't take
that source to another machine.


r~

Re: front end changes for altivec

[Stan Shebs]

Richard Henderson wrote:
> 
> On Tue, Nov 27, 2001 at 03:54:42PM -0600, Aldy Hernandez wrote:
> > not good, because we have "vector int" (V4SI), "vector short" (V8HI),
> > "vector char" (V16QI), etc.  we can't just define "__vector" to expand
> > to a given vector size because that depends on the type being vectored.
> 
> How about __vector_size__(16) then?
> 
> > and then have a default for the given backend+target_switches...
> 
> Absolutely not.  No machine dependant defaults.  You can't take
> that source to another machine.

You mean like how we don't have machine-dependent sizes for int
and long int?

:-)

Stan

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 02:50:22PM -0800, Stan Shebs wrote:
> > Absolutely not.  No machine dependant defaults.  You can't take
> > that source to another machine.
> 
> You mean like how we don't have machine-dependent sizes for int
> and long int?

Exactly!  All the world's a VAX!  ;-)  

Except that I think this is much worse.  At least for "int" you
have sizeof, INT_MAX, CHAR_BITS etc to determine the nature of
the type on the machine.  I think we can do better for vectors.


r~

Re: front end changes for altivec

[Aldy Hernandez]

> 
> Except that I think this is much worse.  At least for "int" you
> have sizeof, INT_MAX, CHAR_BITS etc to determine the nature of
> the type on the machine.  I think we can do better for vectors.

why can't you have sizeof((vector int))?

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

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 06:59:35PM -0600, Aldy Hernandez wrote:
> why can't you have sizeof((vector int))?

Oh, you mean vector_width == sizeof(vector int) / sizeof(int)?
Um, I guess that works.

But what do you do with

	vector int x = (vector int){ 1, 2, 3, 4 };

when a vector is only two elements wide?


r~

Re: front end changes for altivec

[Aldy Hernandez]

On Tue, 2001-11-27 at 19:03, Richard Henderson wrote:
> On Tue, Nov 27, 2001 at 06:59:35PM -0600, Aldy Hernandez wrote:
> > why can't you have sizeof((vector int))?
> 
> Oh, you mean vector_width == sizeof(vector int) / sizeof(int)?
> Um, I guess that works.

right

> But what do you do with
> 
> 	vector int x = (vector int){ 1, 2, 3, 4 };
> 
> when a vector is only two elements wide?

that should trigger a syntax error.  and vector constants should only be
used in initializers.
> 
> 
> r~
-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 07:12:31PM -0600, Aldy Hernandez wrote:
> > But what do you do with
> > 
> > 	vector int x = (vector int){ 1, 2, 3, 4 };
> > 
> > when a vector is only two elements wide?
> 
> that should trigger a syntax error.  and vector constants should only be
> used in initializers.

Then how do you initialize _any_ data across different simd
implementations?


r~

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 07:12:31PM -0600, Aldy Hernandez wrote:
> > But what do you do with
> > 
> > 	vector int x = (vector int){ 1, 2, 3, 4 };
> > 
> > when a vector is only two elements wide?
> 
> that should trigger a syntax error.  and vector constants should only be
> used in initializers.

Then how do you initialize _any_ data across different simd
implementations?


r~

Re: front end changes for altivec

[Aldy Hernandez]

On Tue, 2001-11-27 at 19:03, Richard Henderson wrote:
> On Tue, Nov 27, 2001 at 06:59:35PM -0600, Aldy Hernandez wrote:
> > why can't you have sizeof((vector int))?
> 
> Oh, you mean vector_width == sizeof(vector int) / sizeof(int)?
> Um, I guess that works.

right

> But what do you do with
> 
> 	vector int x = (vector int){ 1, 2, 3, 4 };
> 
> when a vector is only two elements wide?

that should trigger a syntax error.  and vector constants should only be
used in initializers.
> 
> 
> r~
-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

Re: front end changes for altivec

[Alexandre Oliva]

On Nov 27, 2001, Richard Henderson <rth@redhat.com> wrote:

> On Tue, Nov 27, 2001 at 06:59:35PM -0600, Aldy Hernandez wrote:
>> why can't you have sizeof((vector int))?

> Oh, you mean vector_width == sizeof(vector int) / sizeof(int)?
> Um, I guess that works.

> But what do you do with

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

> when a vector is only two elements wide?

How about requiring that variables of type vector always be arrays
with their actual number of elements explicitly specified, or inferred
from the initializer?

We could still support implicit iteration over vector elements for
operations such as copying, addition and subtraction, relieving the
source code from the need to worry about the exact vector size, while
still allowing code to pick into it somehow, for example:

vector int x[] = { 1, 2, 3, 4, 5, 6, 7 }; // probably pads with 0s

vector int y[7];

...

  y = x;
  y = x + y; 

I'm unsure whether indexing such an array (x[n]) would get you the nth
int or the nth vector element.  I'm inclined to prefer the latter,
even though it's a bit odd that you wouldn't be able to get x[6] on
the vector above unless the machine didn't support any int-type vector
mode, such that the int vector size is 1.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: front end changes for altivec

[Daniel Berlin]

On Thursday, November 29, 2001, at 12:00  AM, Alexandre Oliva wrote:

> On Nov 27, 2001, Richard Henderson <rth@redhat.com> wrote:
>
>> On Tue, Nov 27, 2001 at 06:59:35PM -0600, Aldy Hernandez wrote:
>>> why can't you have sizeof((vector int))?
>
>> Oh, you mean vector_width == sizeof(vector int) / sizeof(int)?
>> Um, I guess that works.
>
>> But what do you do with
>
>> 	vector int x = (vector int){ 1, 2, 3, 4 };
>
>> when a vector is only two elements wide?
>
> How about requiring that variables of type vector always be arrays
> with their actual number of elements explicitly specified, or inferred
> from the initializer?
We should be able to infer it.
After, all, all our vector modes are fixed size, and all the vector 
extensions we are talking of supporting have fixed size registers.

While on the subject of vectors I also don't quite see the need for the 
overloaded functions (like altivec specifies). Why can't we just say 
that addition of vectors (IE c=a + b where c, a, b are vectors)  
transforms into
(set (reg:V4SF <reg for c>) (plus:V4SF (reg:V4SF <reg for a>) (reg:V4SF 
<reg for b>))).
This, is, after all, what the intrinsics end up generating anyway.
Are we just waiting for a devectorizing pass that splits vector modes 
not supported by a target machine into supported vectors or non-vectors 
(I'm not talking trying to map onto different element sized 
vector/non-vectors, just smaller ones. Like 2 v2sf's for each v4sf, if 
v2sf was supported by the target and v4sf was not)?
Or am i missing something somehow?
--Dan

Re: front end changes for altivec

[Alexandre Oliva]

On Nov 29, 2001, Daniel Berlin <dan@cgsoftware.com> wrote:

>> How about requiring that variables of type vector always be arrays
>> with their actual number of elements explicitly specified, or inferred
>> from the initializer?

> We should be able to infer it.
> After, all, all our vector modes are fixed size, and all the vector
> extensions we are talking of supporting have fixed size registers.

Nope, I'm talking about letting the program tell the array size it
wants, but letting the compiler decide the vector size to use,
regardless of the array size.  Then, you get the compiler to use
vector operations where available, but the code will work without
changes on machines without vector support, or with vectors of
different length.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: front end changes for altivec

[Daniel Berlin]

On Thursday, November 29, 2001, at 01:33  AM, Alexandre Oliva wrote:

> On Nov 29, 2001, Daniel Berlin <dan@cgsoftware.com> wrote:
>
>>> How about requiring that variables of type vector always be arrays
>>> with their actual number of elements explicitly specified, or inferred
>>> from the initializer?
>
>> We should be able to infer it.
>> After, all, all our vector modes are fixed size, and all the vector
>> extensions we are talking of supporting have fixed size registers.
>
> Nope, I'm talking about letting the program tell the array size it
> wants, but letting the compiler decide the vector size to use,
> regardless of the array size.
*this* is tricky.
Well, okay, it depends on how advanced you want to be when deciding what 
vector size to use.
Even then, thinks like selecting the minimum/maximum of a vector are 
going to be trickier (pick an odd sized vector, you end up with extra 
elements, that you have to know what to fill with so they don't affect 
the answer, if this is even possible).

>   Then, you get the compiler to use
> vector operations where available, but the code will work without
> changes on machines without vector support, or with vectors of
> different length.
>
You can do this without having non-fixed sized vectors.
It's easier to.
It's always going to be much harder to shoehorn things *into* vectors, 
because of alignment issues, etc.
With a non-fixed size vector, this is what you have to do in some cases.
If you just stick to v2, v4, v8, v16, etc, you can always split a v16 
into 2 v8's, a v2 into two non-vectors, etc.
You avoid the alignment issues, dependency fun, etc.
Trying to support non-fixed size vectors, for any non-power of 2, is a 
serious pain.
At least, this is my impression.
Maybe i'm completely off.

--Dan

Re: front end changes for altivec

[Jack Lloyd]

On Thu, 29 Nov 2001, Daniel Berlin wrote:

>
> On Thursday, November 29, 2001, at 01:33  AM, Alexandre Oliva wrote:
>
> > On Nov 29, 2001, Daniel Berlin <dan@cgsoftware.com> wrote:
> >
> >>> How about requiring that variables of type vector always be arrays
> >>> with their actual number of elements explicitly specified, or inferred
> >>> from the initializer?
> >
> >> We should be able to infer it.
> >> After, all, all our vector modes are fixed size, and all the vector
> >> extensions we are talking of supporting have fixed size registers.
> >
> > Nope, I'm talking about letting the program tell the array size it
> > wants, but letting the compiler decide the vector size to use,
> > regardless of the array size.
>
> *this* is tricky.
> Well, okay, it depends on how advanced you want to be when deciding what
> vector size to use.
> Even then, thinks like selecting the minimum/maximum of a vector are
> going to be trickier (pick an odd sized vector, you end up with extra
> elements, that you have to know what to fill with so they don't affect
> the answer, if this is even possible).

Maybe I'm completely off base here, but a pretty sane interpretation of a 9
element unsigned char vector on a machine with (for example) MMX, could be
a single 8 byte long MMX vector along with a single unsigned char. OTOH,
that could be very hard from an actual implementation perspective, I'm no
GCC internals expert (obviously).

BTW, one question about this: is it really reasonble to support essentially
arbitrary length vectors like this? I kind of get the feeling it would be
better for something working on a somewhat higher level (like libstdc++
valarray or a GMP-like library). For example, I can't get arbitrary size
integers with GCC, why should I be able to get abitrary size vectors?

Not meaning to start a flame war or anything (more than has already been
started in this thread <g>), just some thoughts/questions I had...

-Jack

Re: front end changes for altivec

[Jack Lloyd]

On Thu, 29 Nov 2001, Daniel Berlin wrote:

>
> On Thursday, November 29, 2001, at 01:33  AM, Alexandre Oliva wrote:
>
> > On Nov 29, 2001, Daniel Berlin <dan@cgsoftware.com> wrote:
> >
> >>> How about requiring that variables of type vector always be arrays
> >>> with their actual number of elements explicitly specified, or inferred
> >>> from the initializer?
> >
> >> We should be able to infer it.
> >> After, all, all our vector modes are fixed size, and all the vector
> >> extensions we are talking of supporting have fixed size registers.
> >
> > Nope, I'm talking about letting the program tell the array size it
> > wants, but letting the compiler decide the vector size to use,
> > regardless of the array size.
>
> *this* is tricky.
> Well, okay, it depends on how advanced you want to be when deciding what
> vector size to use.
> Even then, thinks like selecting the minimum/maximum of a vector are
> going to be trickier (pick an odd sized vector, you end up with extra
> elements, that you have to know what to fill with so they don't affect
> the answer, if this is even possible).

Maybe I'm completely off base here, but a pretty sane interpretation of a 9
element unsigned char vector on a machine with (for example) MMX, could be
a single 8 byte long MMX vector along with a single unsigned char. OTOH,
that could be very hard from an actual implementation perspective, I'm no
GCC internals expert (obviously).

BTW, one question about this: is it really reasonble to support essentially
arbitrary length vectors like this? I kind of get the feeling it would be
better for something working on a somewhat higher level (like libstdc++
valarray or a GMP-like library). For example, I can't get arbitrary size
integers with GCC, why should I be able to get abitrary size vectors?

Not meaning to start a flame war or anything (more than has already been
started in this thread <g>), just some thoughts/questions I had...

-Jack

Re: front end changes for altivec

[Daniel Berlin]

On Thursday, November 29, 2001, at 01:33  AM, Alexandre Oliva wrote:

> On Nov 29, 2001, Daniel Berlin <dan@cgsoftware.com> wrote:
>
>>> How about requiring that variables of type vector always be arrays
>>> with their actual number of elements explicitly specified, or inferred
>>> from the initializer?
>
>> We should be able to infer it.
>> After, all, all our vector modes are fixed size, and all the vector
>> extensions we are talking of supporting have fixed size registers.
>
> Nope, I'm talking about letting the program tell the array size it
> wants, but letting the compiler decide the vector size to use,
> regardless of the array size.
*this* is tricky.
Well, okay, it depends on how advanced you want to be when deciding what 
vector size to use.
Even then, thinks like selecting the minimum/maximum of a vector are 
going to be trickier (pick an odd sized vector, you end up with extra 
elements, that you have to know what to fill with so they don't affect 
the answer, if this is even possible).

>   Then, you get the compiler to use
> vector operations where available, but the code will work without
> changes on machines without vector support, or with vectors of
> different length.
>
You can do this without having non-fixed sized vectors.
It's easier to.
It's always going to be much harder to shoehorn things *into* vectors, 
because of alignment issues, etc.
With a non-fixed size vector, this is what you have to do in some cases.
If you just stick to v2, v4, v8, v16, etc, you can always split a v16 
into 2 v8's, a v2 into two non-vectors, etc.
You avoid the alignment issues, dependency fun, etc.
Trying to support non-fixed size vectors, for any non-power of 2, is a 
serious pain.
At least, this is my impression.
Maybe i'm completely off.

--Dan

Re: front end changes for altivec

[Alexandre Oliva]

On Nov 29, 2001, Daniel Berlin <dan@cgsoftware.com> wrote:

>> How about requiring that variables of type vector always be arrays
>> with their actual number of elements explicitly specified, or inferred
>> from the initializer?

> We should be able to infer it.
> After, all, all our vector modes are fixed size, and all the vector
> extensions we are talking of supporting have fixed size registers.

Nope, I'm talking about letting the program tell the array size it
wants, but letting the compiler decide the vector size to use,
regardless of the array size.  Then, you get the compiler to use
vector operations where available, but the code will work without
changes on machines without vector support, or with vectors of
different length.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: front end changes for altivec

[Richard Henderson]

On Thu, Nov 29, 2001 at 12:55:16AM -0500, Daniel Berlin wrote:
> that addition of vectors (IE c=a + b where c, a, b are vectors)  
> transforms into
> (set (reg:V4SF <reg for c>) (plus:V4SF (reg:V4SF <reg for a>) (reg:V4SF 
> <reg for b>))).

Yes, that's lovely.  Now what about, say, saturating adds?


r~

Re: front end changes for altivec

[Daniel Berlin]

On Thursday, November 29, 2001, at 02:16  AM, Richard Henderson wrote:

> On Thu, Nov 29, 2001 at 12:55:16AM -0500, Daniel Berlin wrote:
>> that addition of vectors (IE c=a + b where c, a, b are vectors)
>> transforms into
>> (set (reg:V4SF <reg for c>) (plus:V4SF (reg:V4SF <reg for a>) (reg:V4SF
>> <reg for b>))).
>
> Yes, that's lovely.  Now what about, say, saturating adds?
>
>
> r~
Anything that doesn't map easily onto rtl requires builtins.
--Dan

Re: front end changes for altivec

[Daniel Berlin]

On Thursday, November 29, 2001, at 02:16  AM, Richard Henderson wrote:

> On Thu, Nov 29, 2001 at 12:55:16AM -0500, Daniel Berlin wrote:
>> that addition of vectors (IE c=a + b where c, a, b are vectors)
>> transforms into
>> (set (reg:V4SF <reg for c>) (plus:V4SF (reg:V4SF <reg for a>) (reg:V4SF
>> <reg for b>))).
>
> Yes, that's lovely.  Now what about, say, saturating adds?
>
>
> r~
Anything that doesn't map easily onto rtl requires builtins.
--Dan

Re: front end changes for altivec

[Richard Henderson]

On Thu, Nov 29, 2001 at 12:55:16AM -0500, Daniel Berlin wrote:
> that addition of vectors (IE c=a + b where c, a, b are vectors)  
> transforms into
> (set (reg:V4SF <reg for c>) (plus:V4SF (reg:V4SF <reg for a>) (reg:V4SF 
> <reg for b>))).

Yes, that's lovely.  Now what about, say, saturating adds?


r~

Re: front end changes for altivec

[Daniel Berlin]

On Thursday, November 29, 2001, at 12:00  AM, Alexandre Oliva wrote:

> On Nov 27, 2001, Richard Henderson <rth@redhat.com> wrote:
>
>> On Tue, Nov 27, 2001 at 06:59:35PM -0600, Aldy Hernandez wrote:
>>> why can't you have sizeof((vector int))?
>
>> Oh, you mean vector_width == sizeof(vector int) / sizeof(int)?
>> Um, I guess that works.
>
>> But what do you do with
>
>> 	vector int x = (vector int){ 1, 2, 3, 4 };
>
>> when a vector is only two elements wide?
>
> How about requiring that variables of type vector always be arrays
> with their actual number of elements explicitly specified, or inferred
> from the initializer?
We should be able to infer it.
After, all, all our vector modes are fixed size, and all the vector 
extensions we are talking of supporting have fixed size registers.

While on the subject of vectors I also don't quite see the need for the 
overloaded functions (like altivec specifies). Why can't we just say 
that addition of vectors (IE c=a + b where c, a, b are vectors)  
transforms into
(set (reg:V4SF <reg for c>) (plus:V4SF (reg:V4SF <reg for a>) (reg:V4SF 
<reg for b>))).
This, is, after all, what the intrinsics end up generating anyway.
Are we just waiting for a devectorizing pass that splits vector modes 
not supported by a target machine into supported vectors or non-vectors 
(I'm not talking trying to map onto different element sized 
vector/non-vectors, just smaller ones. Like 2 v2sf's for each v4sf, if 
v2sf was supported by the target and v4sf was not)?
Or am i missing something somehow?
--Dan

Re: front end changes for altivec

[Per Bothner]

Alexandre Oliva wrote:

> How about requiring that variables of type vector always be arrays
> with their actual number of elements explicitly specified, or inferred
> from the initializer?
> 
> We could still support implicit iteration over vector elements for
> operations such as copying, addition and subtraction, relieving the
> source code from the need to worry about the exact vector size, while
> still allowing code to pick into it somehow, for example:
> 
> vector int x[] = { 1, 2, 3, 4, 5, 6, 7 }; // probably pads with 0s
> 
> vector int y[7];
> 
> ...
> 
>   y = x;
>   y = x + y; 

My recommendation is to define the extension as syntactic sugar
for a C++ template.  That has the advantage of providing a clean definition.

There happens to be a standard C++ template that seems to closely
match what is needed:  valarray.  This was specifically designed
to be highly optimizable and to be mapped to vector hardware.

My preference:

* We provide hooks so that valarray implementations can run
optimized on suitable hardware, including Altivec and MMX.

* We encourage programmers who want to write efficient code
to use C++ and the valarray type.  They gain the benefits of
making their code both portable and fast.

* If we define a C "vector" extension we define in terms of
the C++ valarray type.  Specifically, there should be no
Altivec-target-dependent functionality or optimizations
that you can access from the C extension that you can't also
access using the valarray template in C++.  I want to encourage
people to write clean portable code, not some kludge.  A
pre-processor that translates from Alticvec C into valarray-using
C++ code would be my preference.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: front end changes for altivec

[Per Bothner]

Alexandre Oliva wrote:

> How about requiring that variables of type vector always be arrays
> with their actual number of elements explicitly specified, or inferred
> from the initializer?
> 
> We could still support implicit iteration over vector elements for
> operations such as copying, addition and subtraction, relieving the
> source code from the need to worry about the exact vector size, while
> still allowing code to pick into it somehow, for example:
> 
> vector int x[] = { 1, 2, 3, 4, 5, 6, 7 }; // probably pads with 0s
> 
> vector int y[7];
> 
> ...
> 
>   y = x;
>   y = x + y; 

My recommendation is to define the extension as syntactic sugar
for a C++ template.  That has the advantage of providing a clean definition.

There happens to be a standard C++ template that seems to closely
match what is needed:  valarray.  This was specifically designed
to be highly optimizable and to be mapped to vector hardware.

My preference:

* We provide hooks so that valarray implementations can run
optimized on suitable hardware, including Altivec and MMX.

* We encourage programmers who want to write efficient code
to use C++ and the valarray type.  They gain the benefits of
making their code both portable and fast.

* If we define a C "vector" extension we define in terms of
the C++ valarray type.  Specifically, there should be no
Altivec-target-dependent functionality or optimizations
that you can access from the C extension that you can't also
access using the valarray template in C++.  I want to encourage
people to write clean portable code, not some kludge.  A
pre-processor that translates from Alticvec C into valarray-using
C++ code would be my preference.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: front end changes for altivec

[Alexandre Oliva]

On Nov 27, 2001, Richard Henderson <rth@redhat.com> wrote:

> On Tue, Nov 27, 2001 at 06:59:35PM -0600, Aldy Hernandez wrote:
>> why can't you have sizeof((vector int))?

> Oh, you mean vector_width == sizeof(vector int) / sizeof(int)?
> Um, I guess that works.

> But what do you do with

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

> when a vector is only two elements wide?

How about requiring that variables of type vector always be arrays
with their actual number of elements explicitly specified, or inferred
from the initializer?

We could still support implicit iteration over vector elements for
operations such as copying, addition and subtraction, relieving the
source code from the need to worry about the exact vector size, while
still allowing code to pick into it somehow, for example:

vector int x[] = { 1, 2, 3, 4, 5, 6, 7 }; // probably pads with 0s

vector int y[7];

...

  y = x;
  y = x + y; 

I'm unsure whether indexing such an array (x[n]) would get you the nth
int or the nth vector element.  I'm inclined to prefer the latter,
even though it's a bit odd that you wouldn't be able to get x[6] on
the vector above unless the machine didn't support any int-type vector
mode, such that the int vector size is 1.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 06:59:35PM -0600, Aldy Hernandez wrote:
> why can't you have sizeof((vector int))?

Oh, you mean vector_width == sizeof(vector int) / sizeof(int)?
Um, I guess that works.

But what do you do with

	vector int x = (vector int){ 1, 2, 3, 4 };

when a vector is only two elements wide?


r~

Re: front end changes for altivec

[Aldy Hernandez]

> 
> Except that I think this is much worse.  At least for "int" you
> have sizeof, INT_MAX, CHAR_BITS etc to determine the nature of
> the type on the machine.  I think we can do better for vectors.

why can't you have sizeof((vector int))?

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

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 02:50:22PM -0800, Stan Shebs wrote:
> > Absolutely not.  No machine dependant defaults.  You can't take
> > that source to another machine.
> 
> You mean like how we don't have machine-dependent sizes for int
> and long int?

Exactly!  All the world's a VAX!  ;-)  

Except that I think this is much worse.  At least for "int" you
have sizeof, INT_MAX, CHAR_BITS etc to determine the nature of
the type on the machine.  I think we can do better for vectors.


r~

Re: front end changes for altivec

[Stan Shebs]

Richard Henderson wrote:
> 
> On Tue, Nov 27, 2001 at 03:54:42PM -0600, Aldy Hernandez wrote:
> > not good, because we have "vector int" (V4SI), "vector short" (V8HI),
> > "vector char" (V16QI), etc.  we can't just define "__vector" to expand
> > to a given vector size because that depends on the type being vectored.
> 
> How about __vector_size__(16) then?
> 
> > and then have a default for the given backend+target_switches...
> 
> Absolutely not.  No machine dependant defaults.  You can't take
> that source to another machine.

You mean like how we don't have machine-dependent sizes for int
and long int?

:-)

Stan

Re: front end changes for altivec

[Aldy Hernandez]

On Tue, 2001-11-27 at 16:00, Richard Henderson wrote:
> On Tue, Nov 27, 2001 at 03:54:42PM -0600, Aldy Hernandez wrote:
> > not good, because we have "vector int" (V4SI), "vector short" (V8HI),
> > "vector char" (V16QI), etc.  we can't just define "__vector" to expand
> > to a given vector size because that depends on the type being vectored.
> 
> How about __vector_size__(16) then?
> 
> > and then have a default for the given backend+target_switches...
> 
> Absolutely not.  No machine dependant defaults.  You can't take
> that source to another machine.

can anyone think of any way to get:

	vector int foo;		/* v4si */
	vector short bar;	/* v2hi */
	vector char hot;	/* v16qi */
	etc

working for altivec in a target independent manner?

if not, it pretty much looks like we need separate non-fsf patches to
get this to work.

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

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 06:52:55PM -0600, Aldy Hernandez wrote:
> > How about __vector_size__(16) then?
> 
> can anyone think of any way to get:
> 
> 	vector int foo;		/* v4si */
> 	vector short bar;	/* v2hi */
> 	vector char hot;	/* v16qi */
> 	etc
> 
> working for altivec in a target independent manner?

Modulo the varying size of "short",

  #define __vector  __attribute__((__vector_size__(16)))

works.  And char/short/int doesn't actually vary *that* widely.
The targets for which these are not 1, 2 and 4 octets wide are
fairly rare, so I'm willing to gloss over that.  Especially
since you can also work around this like so:

	#if SHRT_MAX == 32767
	typedef unsigned short u16;
	#elif INT_MAX == 32767
	typedef unsigned int u16;
	#else
	#error you're strange
	#endif

	__vector u16 foo;

I think for stuff written for gcc itself we should encourage the use
of mode(V4SI), or some other explicit element size + vector width
syntax yet to be determined.


r~

Re: front end changes for altivec

[Aldy Hernandez]

On Tue, 2001-11-27 at 19:01, Richard Henderson wrote:
> On Tue, Nov 27, 2001 at 06:52:55PM -0600, Aldy Hernandez wrote:
> > > How about __vector_size__(16) then?
> > 
> > can anyone think of any way to get:
> > 
> > 	vector int foo;		/* v4si */
> > 	vector short bar;	/* v2hi */
> > 	vector char hot;	/* v16qi */
> > 	etc
> > 
> > working for altivec in a target independent manner?
> 
> Modulo the varying size of "short",
> 
>   #define __vector  __attribute__((__vector_size__(16)))

the thing is that there are builtins that expect V4SI, or V4SF, or
V16QI, etc.  i guess i can have all vectors be V4SI (or vector_size(16))
and cast them (which does nothing, but quiets the parser).

actually, why can't we do this then:

	#define __vector  __attribute__ ((mode(V4SI)))

i still would like to have different modes for different vector types
(short, int, char).


> 
> works.  And char/short/int doesn't actually vary *that* widely.
> The targets for which these are not 1, 2 and 4 octets wide are
> fairly rare, so I'm willing to gloss over that.  Especially
> since you can also work around this like so:
> 
> 	#if SHRT_MAX == 32767
> 	typedef unsigned short u16;
> 	#elif INT_MAX == 32767
> 	typedef unsigned int u16;
> 	#else
> 	#error you're strange
> 	#endif
> 
> 	__vector u16 foo;
> 
> I think for stuff written for gcc itself we should encourage the use
> of mode(V4SI), or some other explicit element size + vector width
> syntax yet to be determined.
> 
> 
> r~
-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

Re: front end changes for altivec

[Dale Johannesen]

On Tuesday, November 27, 2001, at 05:26 PM, Aldy Hernandez wrote:
>
> the thing is that there are builtins that expect V4SI, or V4SF, or
> V16QI, etc.  i guess i can have all vectors be V4SI (or vector_size(16))
> and cast them (which does nothing, but quiets the parser).
>
> actually, why can't we do this then:
>
> 	#define __vector  __attribute__ ((mode(V4SI)))
>
> i still would like to have different modes for different vector types
> (short, int, char).

I got this working both ways and eventually let all vectors be V16QI.
That removes some bloat in rs6000.md and there are somewhat fewer
changes in the target-independent parts of the code (e.g. for casts).
The other way is certainly more convenient for resolving those builtins,
though.  I come from a BE background, so to me a single mode for all
16-byte vector objects seems cleanest, but I'm sure people from
FE backgrounds would disagree.

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 05:40:11PM -0800, Dale Johannesen wrote:
> I come from a BE background, so to me a single mode for all
> 16-byte vector objects seems cleanest, but I'm sure people from
> FE backgrounds would disagree.

This falls down for operations such as saturating addition --
you have to know what the element width is, so that you can
choose the proper instruction.


r~

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 05:40:11PM -0800, Dale Johannesen wrote:
> I come from a BE background, so to me a single mode for all
> 16-byte vector objects seems cleanest, but I'm sure people from
> FE backgrounds would disagree.

This falls down for operations such as saturating addition --
you have to know what the element width is, so that you can
choose the proper instruction.


r~

Re: front end changes for altivec

[Dale Johannesen]

On Tuesday, November 27, 2001, at 05:26 PM, Aldy Hernandez wrote:
>
> the thing is that there are builtins that expect V4SI, or V4SF, or
> V16QI, etc.  i guess i can have all vectors be V4SI (or vector_size(16))
> and cast them (which does nothing, but quiets the parser).
>
> actually, why can't we do this then:
>
> 	#define __vector  __attribute__ ((mode(V4SI)))
>
> i still would like to have different modes for different vector types
> (short, int, char).

I got this working both ways and eventually let all vectors be V16QI.
That removes some bloat in rs6000.md and there are somewhat fewer
changes in the target-independent parts of the code (e.g. for casts).
The other way is certainly more convenient for resolving those builtins,
though.  I come from a BE background, so to me a single mode for all
16-byte vector objects seems cleanest, but I'm sure people from
FE backgrounds would disagree.

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 07:26:34PM -0600, Aldy Hernandez wrote:
> > Modulo the varying size of "short",
> > 
> >   #define __vector  __attribute__((__vector_size__(16)))
> 
> the thing is that there are builtins that expect V4SI, or V4SF, or
> V16QI, etc.  i guess i can have all vectors be V4SI (or vector_size(16))
> and cast them (which does nothing, but quiets the parser).

Examine the type that __vector is modifying ("short" for this example)
and you get HImode.  Divide vector_size(16) by sizeof(HImode) to yield 8.
Put it all together and to get V8HImode.  Voila.


r~

Re: front end changes for altivec-- conclusion

[Aldy Hernandez]

On Tue, 2001-11-27 at 19:50, Richard Henderson wrote:
> On Tue, Nov 27, 2001 at 07:26:34PM -0600, Aldy Hernandez wrote:
> > > Modulo the varying size of "short",
> > > 
> > >   #define __vector  __attribute__((__vector_size__(16)))
> > 
> > the thing is that there are builtins that expect V4SI, or V4SF, or
> > V16QI, etc.  i guess i can have all vectors be V4SI (or vector_size(16))
> > and cast them (which does nothing, but quiets the parser).
> 
> Examine the type that __vector is modifying ("short" for this example)
> and you get HImode.  Divide vector_size(16) by sizeof(HImode) to yield 8.
> Put it all together and to get V8HImode.  Voila.

thanks.

ok guys, i think i have all the pieces of the puzzle thanks to a nice
conversation with richard.(modulo that ()'s crap for initializers--
that'll have to be non FSFable patches).

i think it looks like:

	#define __vector __attribute__((__vector_size__(16)))

then find out the mode from the type being modified...  V16QI in the
following example:

	__vector signed char foo;

from then everything falls nicely into place.  

in a couple weeks i'll start implementing the infrastructure along with
an altivec implementation.  

i'm taking volunteers for the x86 version :).

enough talking, back to hacking.

aldy

Re: front end changes for altivec-- conclusion

[Aldy Hernandez]

On Tue, 2001-11-27 at 19:50, Richard Henderson wrote:
> On Tue, Nov 27, 2001 at 07:26:34PM -0600, Aldy Hernandez wrote:
> > > Modulo the varying size of "short",
> > > 
> > >   #define __vector  __attribute__((__vector_size__(16)))
> > 
> > the thing is that there are builtins that expect V4SI, or V4SF, or
> > V16QI, etc.  i guess i can have all vectors be V4SI (or vector_size(16))
> > and cast them (which does nothing, but quiets the parser).
> 
> Examine the type that __vector is modifying ("short" for this example)
> and you get HImode.  Divide vector_size(16) by sizeof(HImode) to yield 8.
> Put it all together and to get V8HImode.  Voila.

thanks.

ok guys, i think i have all the pieces of the puzzle thanks to a nice
conversation with richard.(modulo that ()'s crap for initializers--
that'll have to be non FSFable patches).

i think it looks like:

	#define __vector __attribute__((__vector_size__(16)))

then find out the mode from the type being modified...  V16QI in the
following example:

	__vector signed char foo;

from then everything falls nicely into place.  

in a couple weeks i'll start implementing the infrastructure along with
an altivec implementation.  

i'm taking volunteers for the x86 version :).

enough talking, back to hacking.

aldy

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 07:26:34PM -0600, Aldy Hernandez wrote:
> > Modulo the varying size of "short",
> > 
> >   #define __vector  __attribute__((__vector_size__(16)))
> 
> the thing is that there are builtins that expect V4SI, or V4SF, or
> V16QI, etc.  i guess i can have all vectors be V4SI (or vector_size(16))
> and cast them (which does nothing, but quiets the parser).

Examine the type that __vector is modifying ("short" for this example)
and you get HImode.  Divide vector_size(16) by sizeof(HImode) to yield 8.
Put it all together and to get V8HImode.  Voila.


r~

Re: front end changes for altivec

[Aldy Hernandez]

On Tue, 2001-11-27 at 19:01, Richard Henderson wrote:
> On Tue, Nov 27, 2001 at 06:52:55PM -0600, Aldy Hernandez wrote:
> > > How about __vector_size__(16) then?
> > 
> > can anyone think of any way to get:
> > 
> > 	vector int foo;		/* v4si */
> > 	vector short bar;	/* v2hi */
> > 	vector char hot;	/* v16qi */
> > 	etc
> > 
> > working for altivec in a target independent manner?
> 
> Modulo the varying size of "short",
> 
>   #define __vector  __attribute__((__vector_size__(16)))

the thing is that there are builtins that expect V4SI, or V4SF, or
V16QI, etc.  i guess i can have all vectors be V4SI (or vector_size(16))
and cast them (which does nothing, but quiets the parser).

actually, why can't we do this then:

	#define __vector  __attribute__ ((mode(V4SI)))

i still would like to have different modes for different vector types
(short, int, char).


> 
> works.  And char/short/int doesn't actually vary *that* widely.
> The targets for which these are not 1, 2 and 4 octets wide are
> fairly rare, so I'm willing to gloss over that.  Especially
> since you can also work around this like so:
> 
> 	#if SHRT_MAX == 32767
> 	typedef unsigned short u16;
> 	#elif INT_MAX == 32767
> 	typedef unsigned int u16;
> 	#else
> 	#error you're strange
> 	#endif
> 
> 	__vector u16 foo;
> 
> I think for stuff written for gcc itself we should encourage the use
> of mode(V4SI), or some other explicit element size + vector width
> syntax yet to be determined.
> 
> 
> r~
-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 06:52:55PM -0600, Aldy Hernandez wrote:
> > How about __vector_size__(16) then?
> 
> can anyone think of any way to get:
> 
> 	vector int foo;		/* v4si */
> 	vector short bar;	/* v2hi */
> 	vector char hot;	/* v16qi */
> 	etc
> 
> working for altivec in a target independent manner?

Modulo the varying size of "short",

  #define __vector  __attribute__((__vector_size__(16)))

works.  And char/short/int doesn't actually vary *that* widely.
The targets for which these are not 1, 2 and 4 octets wide are
fairly rare, so I'm willing to gloss over that.  Especially
since you can also work around this like so:

	#if SHRT_MAX == 32767
	typedef unsigned short u16;
	#elif INT_MAX == 32767
	typedef unsigned int u16;
	#else
	#error you're strange
	#endif

	__vector u16 foo;

I think for stuff written for gcc itself we should encourage the use
of mode(V4SI), or some other explicit element size + vector width
syntax yet to be determined.


r~

Re: front end changes for altivec

[Aldy Hernandez]

On Tue, 2001-11-27 at 16:00, Richard Henderson wrote:
> On Tue, Nov 27, 2001 at 03:54:42PM -0600, Aldy Hernandez wrote:
> > not good, because we have "vector int" (V4SI), "vector short" (V8HI),
> > "vector char" (V16QI), etc.  we can't just define "__vector" to expand
> > to a given vector size because that depends on the type being vectored.
> 
> How about __vector_size__(16) then?
> 
> > and then have a default for the given backend+target_switches...
> 
> Absolutely not.  No machine dependant defaults.  You can't take
> that source to another machine.

can anyone think of any way to get:

	vector int foo;		/* v4si */
	vector short bar;	/* v2hi */
	vector char hot;	/* v16qi */
	etc

working for altivec in a target independent manner?

if not, it pretty much looks like we need separate non-fsf patches to
get this to work.

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

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 03:54:42PM -0600, Aldy Hernandez wrote:
> not good, because we have "vector int" (V4SI), "vector short" (V8HI),
> "vector char" (V16QI), etc.  we can't just define "__vector" to expand
> to a given vector size because that depends on the type being vectored.

How about __vector_size__(16) then?

> and then have a default for the given backend+target_switches...

Absolutely not.  No machine dependant defaults.  You can't take
that source to another machine.


r~

Re: front end changes for altivec

[Aldy Hernandez]

> I prefer
> 
> 	int foo __attribute__((vector(4)));
> 
> which, iirc, also works as a prefix,
> 
> 	__attribute__((vector(4))) int foo;
> 
> which, with appropriate cpp magic in <altivec.h> becomes
> 
> #define __vector  __attribute__((__vector__(4)))
> 
> 	__vector int foo;

not good, because we have "vector int" (V4SI), "vector short" (V8HI),
"vector char" (V16QI), etc.  we can't just define "__vector" to expand
to a given vector size because that depends on the type being vectored.

i still prefer :):

	__vector(4) int foo;

and then have a default for the given backend+target_switches:

	__vector int foo;

a clean implementation IMO.

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

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 09:24:03AM -0600, Aldy Hernandez wrote:
> do we really need to specify a vector size?

Yes.  This documents the intention of the author of the code.

With such, one could write generic code to handle the case that
the machine does not support SIMD at all, or that the machine
supports SIMD but in a narrower mode written in the source.

It also lets the author write code with larger vector sizes (8, 16, 32...)
and have the compiler automatically decompose into whatever the
machine can actually handle.  Which might possibly give the 
compiler more information and let it optimize better.  Dunno
for sure about that, but it's not implausable.

> 	vector(4) int foo;
> 	vector<4> int foo;

I prefer

	int foo __attribute__((vector(4)));

which, iirc, also works as a prefix,

	__attribute__((vector(4))) int foo;

which, with appropriate cpp magic in <altivec.h> becomes

#define __vector  __attribute__((__vector__(4)))

	__vector int foo;

which merely leaves you the c++ nastiness problem with
"vector" vs "__vector" vs "std::vector".


r~

Re: front end changes for altivec

[Aldy Hernandez]

> The answer from some quarters might be "vector int<4>" or "vector<4> int",
> but this adds complications to the C grammar I don't really want there
> since > can be part of a constant expression (so if going that way then do
> as many as possible of defining disambiguating rules by reference to
> existing practice, proving the existence or nonexistence of ambiguous
> cases, describing how the parsing should be implemented).  Or use
> "vector(4)".  Or add some other way of specifying a non-default vector

i've thought about this some more.

do we really need to specify a vector size?  simd architectures
generally have a specific vector size, 64bits for sse* and 128bits for
altivec.  

so, "vector int x" in sse* means V2SI, provided ints are 32bits.

in altivec, "vector int" means V4SI, provided ints are 32bits.

so do we _really_ need to specify a size or can it be determined from
backend info?

if we really do need to specify vector size, then either of your
proposals will work:

	vector(4) int foo;
	vector<4> int foo;

(i really don't like "vector int<4> foo" :))

what do you suggest <> or ()?

furthermore, we need to have a default vector size for the altivec stuff
to work-- and it makes for prettier code :).  so:

	vector int foo	--> V4SI in altivec
	vector int foo	--> V2SI in SSE*
	etc

we would need defaults for vector + [int, short, bool, char, float]. 
for this, we could add a macro to gcc that given an SI/HI/QI/SF returns
an V4SI/V8HI/V18QI/V4SF.  this seems like the cleanest idea.

how does this sound?

aldy

Re: front end changes for altivec

[Joseph S. Myers]

On Mon, 26 Nov 2001, Aldy Hernandez wrote:

> __vector must be first among type specifiers.  the specs are rather skekchy,

That's not consistent with how other type specifiers work.  It would make
more sense for the list of possible type specifier combinations to include
such things as "__vector signed int" and any permutation thereof.

> ok, but how would we differentiate between the diff vector sizes.
> altivec has "vector int" being V4SI, but vector int could mean V2SI in
> mmx.  suggestion welcome while i think through this.

The answer from some quarters might be "vector int<4>" or "vector<4> int",
but this adds complications to the C grammar I don't really want there
since > can be part of a constant expression (so if going that way then do
as many as possible of defining disambiguating rules by reference to
existing practice, proving the existence or nonexistence of ambiguous
cases, describing how the parsing should be implemented).  Or use
"vector(4)".  Or add some other way of specifying a non-default vector
size.

> correct.  you can't convert between any of the vector types.  the following
> just does a straight copy, no conversion (nop):
> 
>   vector short b;
>   vector int a = (vector int) b;

What about other operations, e.g. arithmetic?

> 	vector int foo = ((vector int)(1,2,3,4));
> 
> this kinda sucks all together because i don't think gcc has vector constants
> at all, do we?  we could pass it as a BLKmode or as a struct right?

I think you should just use the C99 compound literal syntax here (with
braces, not parentheses).  Presumably the ABI says how such arguments are
passed.

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

Re: front end changes for altivec

[Aldy Hernandez]

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

i believe it can only be used with signed, unsigned, int, short, float,
and char.  you can't use it with typedefs or enums.

> can't be used with typedefs, structs or unions.  Can it be used with

but they can be used as fields in a struct.

> enums?  Why those particular sizes of vectors rather than others?  Will
> __vector on its own imply __vector int?

__vector must be first among type specifiers.  the specs are rather skekchy,
but it seems like you need to specifically mention int.  you can also
have pointers to these types (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

ok, but how would we differentiate between the diff vector sizes.
altivec has "vector int" being V4SI, but vector int could mean V2SI in
mmx.  suggestion welcome while i think through this.

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

correct.  you can't convert between any of the vector types.  the following
just does a straight copy, no conversion (nop):

  vector short b;
  vector int a = (vector int) b;

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

oh sorry, it has to be casted and it has to have an extra set of ()'s so
it might not be too bad:

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

this kinda sucks all together because i don't think gcc has vector constants
at all, do we?  we could pass it as a BLKmode or as a struct right?

this might not be too bad if we come up with a mechanism for all simd 
processors.  i'm still wondering how to manage the diff sizes.

does this make it clearer?

aldy

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 foraltivec)

[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)

[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 foraltivec)

[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

[Joe Buck]

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

I suggest that the next step is to formally document the proposal, and
then to figure out what remaining differences there are.  That is, with
"appropriate macroization", is the only difference the {} vs () for
constants?  Or are there other issues as well?

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

[Joe Buck]

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

I suggest that the next step is to formally document the proposal, and
then to figure out what remaining differences there are.  That is, with
"appropriate macroization", is the only difference the {} vs () for
constants?  Or are there other issues as well?

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

[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 foraltivec)

[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)

[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 foraltivec)

[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)

[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

[Joe Buck]

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

Allowing "vector" to be a macro would be completely unacceptable, because
people will mix C and C++ code.

> Other things are more difficult.  Vector literals should just be
> C99 compound literals, but I'm not sure whether we can get away
> with changing that or not.

A modest proposal:

Consider a preprocessor that takes current Altivec C code and produces
either standard or extended C code (GNU extensions).  If adopting the
existing Altivec syntax is too painful, a second choice might be to figure
out syntax choices that would make such a preprocessor very easy to write.
Then we don't have to ask existing users to rewrite their code.

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

[Mark Mitchell]

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

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

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

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

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

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

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

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

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

[Joe Buck]

I wrote:
> > Consider a preprocessor that takes current Altivec C code and produces
> > either standard or extended C code (GNU extensions).  If adopting the
> > existing Altivec syntax is too painful, a second choice might be to figure
> > out syntax choices that would make such a preprocessor very easy to write.
> > Then we don't have to ask existing users to rewrite their code.

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

It wouldn't necessarily be up to the gcc team to deliver the preprocessor.
A 100% correct version would be substantial, as it would have to be a full
parser, but a more limited Perl or Python whack-job might handle almost
all the existing code.

The proposal is really only meant as an answer to those who say that we
cannot change the syntax at all because users won't want to change their
code.

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

[Joe Buck]

I wrote:
> > Consider a preprocessor that takes current Altivec C code and produces
> > either standard or extended C code (GNU extensions).  If adopting the
> > existing Altivec syntax is too painful, a second choice might be to figure
> > out syntax choices that would make such a preprocessor very easy to write.
> > Then we don't have to ask existing users to rewrite their code.

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

It wouldn't necessarily be up to the gcc team to deliver the preprocessor.
A 100% correct version would be substantial, as it would have to be a full
parser, but a more limited Perl or Python whack-job might handle almost
all the existing code.

The proposal is really only meant as an answer to those who say that we
cannot change the syntax at all because users won't want to change their
code.

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

[Devang Patel]

On Tuesday, November 27, 2001, at 03:26  PM, Mark Mitchell wrote:

>
>
> --On Tuesday, November 27, 2001 02:53:26 PM -0800 Joe Buck 
> <jbuck@synopsys.COM> wrote:
>
>> Mark writes:
>>> Concretely, the Altivec specification allows "vector" to be either a
>>> macro, or a context-sensitive keyword.  The latter is a much better
>>> choice, and it is the one we should adopt in GCC.  It will be far
>>> less intrusive.
>>
>> Allowing "vector" to be a macro would be completely unacceptable, 
>> because
>> people will mix C and C++ code.
>
> The Altivec specification says that __vector is a keyword.  It says that
> vector can be either a macro or a context-sensitive keyword.  If it
> is a macro you are explicitly allowed to #undef it.
>
> So, you can use __vector in C or C++, with any Altivec compiler.  If
> you're using (Altivec) vector in C++ code, you're not writing
> portable code, even across Altivec implementations.

I think, main reason to make vector context-sensitive keyword was -- 
allow it
to coexist with C++ stl vector.

If context-sensitive keyword is highly undesirable then bettor solution 
is to
only support __vector and drop vector macro. And force user to
adapt __vector keyword. If user complains, we can always point him/her to
this thread :-)

I would also resist the temptation to support vector macro only for C.

Devang

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

[Devang Patel]

On Tuesday, November 27, 2001, at 03:26  PM, Mark Mitchell wrote:

>
>
> --On Tuesday, November 27, 2001 02:53:26 PM -0800 Joe Buck 
> <jbuck@synopsys.COM> wrote:
>
>> Mark writes:
>>> Concretely, the Altivec specification allows "vector" to be either a
>>> macro, or a context-sensitive keyword.  The latter is a much better
>>> choice, and it is the one we should adopt in GCC.  It will be far
>>> less intrusive.
>>
>> Allowing "vector" to be a macro would be completely unacceptable, 
>> because
>> people will mix C and C++ code.
>
> The Altivec specification says that __vector is a keyword.  It says that
> vector can be either a macro or a context-sensitive keyword.  If it
> is a macro you are explicitly allowed to #undef it.
>
> So, you can use __vector in C or C++, with any Altivec compiler.  If
> you're using (Altivec) vector in C++ code, you're not writing
> portable code, even across Altivec implementations.

I think, main reason to make vector context-sensitive keyword was -- 
allow it
to coexist with C++ stl vector.

If context-sensitive keyword is highly undesirable then bettor solution 
is to
only support __vector and drop vector macro. And force user to
adapt __vector keyword. If user complains, we can always point him/her to
this thread :-)

I would also resist the temptation to support vector macro only for C.

Devang

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

[Aldy Hernandez]

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

 >> Consider a preprocessor that takes current Altivec C code and produces
 >> either standard or extended C code (GNU extensions).  If adopting the
 >> existing Altivec syntax is too painful, a second choice might be to figure
 >> out syntax choices that would make such a preprocessor very easy to write.
 >> Then we don't have to ask existing users to rewrite their code.

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

I've actually thought about implementing generic front end extension
support to gcc for this kind of nonsense.  Sort of like a preprocessor
that runs after the actual C preprocessor-- massages the output in any
way it sees fit, and feeds its output to the lexical analyzer.

This way if someone wants to implement some brain dead front end
extension widely used somewhere else, it could be a plugin-- and we
could offer a whole slew of plugins in the future (altivec plugins,
msoft inline assembly plugin, etc etc).

That sounds like a good project :)

what do y'all think?

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

[Ziemowit Laski]

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

> I've actually thought about implementing generic front end extension
> support to gcc for this kind of nonsense.  Sort of like a preprocessor
> that runs after the actual C preprocessor-- massages the output in any
> way it sees fit, and feeds its output to the lexical analyzer.
>
> This way if someone wants to implement some brain dead front end
> extension widely used somewhere else, it could be a plugin-- and we
> could offer a whole slew of plugins in the future (altivec plugins,
> msoft inline assembly plugin, etc etc).
>
> That sounds like a good project :)

Well, it definitely sounds interesting!  Tell me more. :) :)
--------------------------------------------------------------
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

[Aldy Hernandez]

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

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

 >> I've actually thought about implementing generic front end extension
 >> support to gcc for this kind of nonsense.  Sort of like a preprocessor
 >> that runs after the actual C preprocessor-- massages the output in any
 >> way it sees fit, and feeds its output to the lexical analyzer.
 >> 
 >> This way if someone wants to implement some brain dead front end
 >> extension widely used somewhere else, it could be a plugin-- and we
 >> could offer a whole slew of plugins in the future (altivec plugins,
 >> msoft inline assembly plugin, etc etc).
 >> 
 >> That sounds like a good project :)

 > Well, it definitely sounds interesting!  Tell me more. :) :)

simple, it just reads the output from CPP, manipulates the strings,
and, feeds it's output to the lexer.

You would register your extension before the lexer starts doing it's
thing.

Code is worth a thousand words:

        typedef char * (*fe_extension)(char *);

        char *
        altivec_extension (char *line)
        {
                char *p;

                p = altivec_massage (line);
                return p;
        }

        void
        lexer_setup()
        {
                ...
                if (TARGET_ALTIVEC)
                        register_fe_extension (altivec_extension);
                ...
        }

        int
        lex ()
        {
                ...
                c = extended_lexer ();
                ...
        }

        int
        extended_lexer ()
        {
                char *p;
                static char *q;
                int i;

                if (!q || !*q) {
                        p = read_next_line ();

                        /* Massage the current line with all the FE
                           extensions applicable.  */
                        for (i = 0; i < total_fe_extensions; i++)
                                q = (fe_extension[i])(p);
                }

                return *q++;
        }

that's the general idea.  The assumption is that most FE extensions
can be translated into something saner involving intrinsics or
something more gcc-able.  The goal is not to provide an entire parser
in each extension, but to come up with a set of heuristics that will
do string replacements.

In cases where we need context, the extension could keep a few state
variables to know what it's seen so far and what it expects.  Nothing
too complicated, just to get the job done.

One simple example would be for the altivec extension to recognize

        ...(1,2,3,4)

in an initializer and merely replace it with {}'s.

...and I'm taking volunteers for this project :)

Aldy

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

[Joe Buck]

Tuesday, November 27, 2001, at 06:23 , Aldy Hernandez wrote:
> 
>  >> I've actually thought about implementing generic front end extension
>  >> support to gcc for this kind of nonsense.  Sort of like a preprocessor
>  >> that runs after the actual C preprocessor-- massages the output in any
>  >> way it sees fit, and feeds its output to the lexical analyzer.
...

>  > Well, it definitely sounds interesting!  Tell me more. :) :)

Aldy again:
> simple, it just reads the output from CPP, manipulates the strings,
> and, feeds it's output to the lexer.

But we no longer use a separate preprocessing program.  We now use cpplib,
integrating preprocessing with lexing for the main compiler.

I suppose that you could still insert a pass that looks like the C++
"spew" hack (implement a token queue to allow for extra lookahead
and re-labeling of tokens).

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

[Aldy Hernandez]

On Wed, 2001-11-28 at 11:11, Joe Buck wrote:
> Tuesday, November 27, 2001, at 06:23 , Aldy Hernandez wrote:
> > 
> >  >> I've actually thought about implementing generic front end extension
> >  >> support to gcc for this kind of nonsense.  Sort of like a preprocessor
> >  >> that runs after the actual C preprocessor-- massages the output in any
> >  >> way it sees fit, and feeds its output to the lexical analyzer.
> ...
> 
> >  > Well, it definitely sounds interesting!  Tell me more. :) :)
> 
> Aldy again:
> > simple, it just reads the output from CPP, manipulates the strings,
> > and, feeds it's output to the lexer.
> 
> But we no longer use a separate preprocessing program.  We now use cpplib,
> integrating preprocessing with lexing for the main compiler.

doesn't matter.  just put the FE extension somewhere after cpplib and
before the lexical analyzer.

> 
> I suppose that you could still insert a pass that looks like the C++
> "spew" hack (implement a token queue to allow for extra lookahead
> and re-labeling of tokens).
-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

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

[Neil Booth]

Aldy Hernandez wrote:-

> doesn't matter.  just put the FE extension somewhere after cpplib and
> before the lexical analyzer.

Hmm.  The lexical analyzer is in cpplib.  8-)  I think you mean parser.

Neil.

Input Stream Rewriting (Was: Target-specific Front-Ends?)

[Ziemowit Laski]

(I changed the Subject heading, since I now assume my modular FE proposal
has been sufficiently discussed -- and rejected...)


On Wednesday, November 28, 2001, at 11:06 , Neil Booth wrote:

> Aldy Hernandez wrote:-
>
>> doesn't matter.  just put the FE extension somewhere after cpplib and
>> before the lexical analyzer.
>
> Hmm.  The lexical analyzer is in cpplib.  8-)  I think you mean parser.

Actually, my vote would be to place the functionality in the lexical
analyzer in cpplib (so that it would also be present in the stand-alone 
CPP),
where essentially you rewrite the token stream right before it comes out.

--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: Input Stream Rewriting (Was: Target-specific Front-Ends?)

[Neil Booth]

Ziemowit Laski wrote:-

> Actually, my vote would be to place the functionality in the lexical
> analyzer in cpplib (so that it would also be present in the stand-alone 
> CPP),
> where essentially you rewrite the token stream right before it comes out.

That gets a very big thumbs down from me.  I don't want any more
extraneous stuff added to CPP.

Neil.

Re: Input Stream Rewriting (Was: Target-specific Front-Ends?)

[Ziemowit Laski]

On Wednesday, November 28, 2001, at 12:46 , Neil Booth wrote:

>> Actually, my vote would be to place the functionality in the lexical
>> analyzer in cpplib (so that it would also be present in the stand-alone
>> CPP),
>> where essentially you rewrite the token stream right before it comes 
>> out.
>
> That gets a very big thumbs down from me.  I don't want any more
> extraneous stuff added to CPP.

I assume your reasons have to do with performance -- or am I wrong?

--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: Input Stream Rewriting (Was: Target-specific Front-Ends?)

[Neil Booth]

Ziemowit Laski wrote:-

> I assume your reasons have to do with performance -- or am I wrong?

That, cleanliness, and the fact that cpplib is a token preprocessor,
not a text preprocessor.

Neil.

Re: Input Stream Rewriting (Was: Target-specific Front-Ends?)

[Neil Booth]

Ziemowit Laski wrote:-

> I assume your reasons have to do with performance -- or am I wrong?

That, cleanliness, and the fact that cpplib is a token preprocessor,
not a text preprocessor.

Neil.

Re: Input Stream Rewriting (Was: Target-specific Front-Ends?)

[Ziemowit Laski]

On Wednesday, November 28, 2001, at 12:46 , Neil Booth wrote:

>> Actually, my vote would be to place the functionality in the lexical
>> analyzer in cpplib (so that it would also be present in the stand-alone
>> CPP),
>> where essentially you rewrite the token stream right before it comes 
>> out.
>
> That gets a very big thumbs down from me.  I don't want any more
> extraneous stuff added to CPP.

I assume your reasons have to do with performance -- or am I wrong?

--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: Input Stream Rewriting (Was: Target-specific Front-Ends?)

[Neil Booth]

Ziemowit Laski wrote:-

> Actually, my vote would be to place the functionality in the lexical
> analyzer in cpplib (so that it would also be present in the stand-alone 
> CPP),
> where essentially you rewrite the token stream right before it comes out.

That gets a very big thumbs down from me.  I don't want any more
extraneous stuff added to CPP.

Neil.

Input Stream Rewriting (Was: Target-specific Front-Ends?)

[Ziemowit Laski]

(I changed the Subject heading, since I now assume my modular FE proposal
has been sufficiently discussed -- and rejected...)


On Wednesday, November 28, 2001, at 11:06 , Neil Booth wrote:

> Aldy Hernandez wrote:-
>
>> doesn't matter.  just put the FE extension somewhere after cpplib and
>> before the lexical analyzer.
>
> Hmm.  The lexical analyzer is in cpplib.  8-)  I think you mean parser.

Actually, my vote would be to place the functionality in the lexical
analyzer in cpplib (so that it would also be present in the stand-alone 
CPP),
where essentially you rewrite the token stream right before it comes out.

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

[Neil Booth]

Aldy Hernandez wrote:-

> doesn't matter.  just put the FE extension somewhere after cpplib and
> before the lexical analyzer.

Hmm.  The lexical analyzer is in cpplib.  8-)  I think you mean parser.

Neil.

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

[Aldy Hernandez]

On Wed, 2001-11-28 at 11:11, Joe Buck wrote:
> Tuesday, November 27, 2001, at 06:23 , Aldy Hernandez wrote:
> > 
> >  >> I've actually thought about implementing generic front end extension
> >  >> support to gcc for this kind of nonsense.  Sort of like a preprocessor
> >  >> that runs after the actual C preprocessor-- massages the output in any
> >  >> way it sees fit, and feeds its output to the lexical analyzer.
> ...
> 
> >  > Well, it definitely sounds interesting!  Tell me more. :) :)
> 
> Aldy again:
> > simple, it just reads the output from CPP, manipulates the strings,
> > and, feeds it's output to the lexer.
> 
> But we no longer use a separate preprocessing program.  We now use cpplib,
> integrating preprocessing with lexing for the main compiler.

doesn't matter.  just put the FE extension somewhere after cpplib and
before the lexical analyzer.

> 
> I suppose that you could still insert a pass that looks like the C++
> "spew" hack (implement a token queue to allow for extra lookahead
> and re-labeling of tokens).
-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

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

[Joe Buck]

Tuesday, November 27, 2001, at 06:23 , Aldy Hernandez wrote:
> 
>  >> I've actually thought about implementing generic front end extension
>  >> support to gcc for this kind of nonsense.  Sort of like a preprocessor
>  >> that runs after the actual C preprocessor-- massages the output in any
>  >> way it sees fit, and feeds its output to the lexical analyzer.
...

>  > Well, it definitely sounds interesting!  Tell me more. :) :)

Aldy again:
> simple, it just reads the output from CPP, manipulates the strings,
> and, feeds it's output to the lexer.

But we no longer use a separate preprocessing program.  We now use cpplib,
integrating preprocessing with lexing for the main compiler.

I suppose that you could still insert a pass that looks like the C++
"spew" hack (implement a token queue to allow for extra lookahead
and re-labeling of tokens).

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

[Ziemowit Laski]

On Wednesday, November 28, 2001, at 07:36 , Aldy Hernandez wrote:

>>>>>> "Ziemowit" == Ziemowit Laski <zlaski@apple.com> writes:
>
>> On Tuesday, November 27, 2001, at 06:23 , Aldy Hernandez wrote:
>
>>> I've actually thought about implementing generic front end extension
>>> support to gcc for this kind of nonsense.  Sort of like a preprocessor
>>> that runs after the actual C preprocessor-- massages the output in any
>>> way it sees fit, and feeds its output to the lexical analyzer.
>>>
>>> This way if someone wants to implement some brain dead front end
>>> extension widely used somewhere else, it could be a plugin-- and we
>>> could offer a whole slew of plugins in the future (altivec plugins,
>>> msoft inline assembly plugin, etc etc).
>>>
>>> That sounds like a good project :)
>
>> Well, it definitely sounds interesting!  Tell me more. :) :)
>
> simple, it just reads the output from CPP, manipulates the strings,
> and, feeds it's output to the lexer.

Interesting idea.  I was thinking along the lines of putting this
functionality into the back-end of CPP itself (so that you can use -E
to see how the code is being rewritten), and instead of dealing with
raw source lines operate on the resulting token stream (i.e., rearrange,
insert, remove tokens) before passing it out.  But I think we're 
basically
on the same page.

I wouldn't mind COLLABORATING with someone on this (I don't think I have
sufficient cycles left in my day to go it alone).  But first and 
foremost,
I'd like to have some sort of a statement from the SC specifying the
technical parameters of an acceptable solution -- in other words, a
guarantee that if a solution meeting those criteria is created, it will
be accepted.  No more Pascal string work from me. :) :)

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

[Joe Buck]

Ziemowit Laski writes:
> I'd like to have some sort of a statement from the SC specifying the
> technical parameters of an acceptable solution -- in other words, a
> guarantee that if a solution meeting those criteria is created, it will
> be accepted.  No more Pascal string work from me. :) :)

The SC generally works by consensus -- if there's a controversy we have
a problem because our rules require a 3/4 vote.  If people work something
acceptable out on this list, I am sure that it will be accepted.  But
the SC's job is not to do a technical design, and it would be difficult
to write a blank check in advance.  After all, if we forget something and
we are then presented with a patch that would damage gcc's maintainability
in some way we hadn't thought of, plus a copy of our signed guarantee,
what then?  So I'm afraid that all we can offer is good will and
willingness to work with you to find a solution, iterating until complete.
If we can't come to an agreement, at the very least the size of the
patches that you'd have to maintain separately should be substantially
reduced.

It seems that there is some convergence going on around the idea that GCC
would support a syntax similar to Altivec but in some senses more general,
but with at least one difference in that vector literals would be C99
style, plus possibly an optional alteration in preprocessing to allow
existing syntax to be handled.  I think that there's some jumping of the
gun going on: you're proposing solutions before the problem has been fully
defined.  What will the GCC syntax be (and what are the semantics)?  This
determines what kind of rewriting you have to do.  Also, is lexing alone
strong enough to do the conversion, or do you need parsing as well?  The
vector literals aren't regular expressions, since constant expressions are
allowed, but if all you need is the ability to count nesting depth in
parentheses this isn't so bad.

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

[Joe Buck]

Ziemowit Laski writes:
> I'd like to have some sort of a statement from the SC specifying the
> technical parameters of an acceptable solution -- in other words, a
> guarantee that if a solution meeting those criteria is created, it will
> be accepted.  No more Pascal string work from me. :) :)

The SC generally works by consensus -- if there's a controversy we have
a problem because our rules require a 3/4 vote.  If people work something
acceptable out on this list, I am sure that it will be accepted.  But
the SC's job is not to do a technical design, and it would be difficult
to write a blank check in advance.  After all, if we forget something and
we are then presented with a patch that would damage gcc's maintainability
in some way we hadn't thought of, plus a copy of our signed guarantee,
what then?  So I'm afraid that all we can offer is good will and
willingness to work with you to find a solution, iterating until complete.
If we can't come to an agreement, at the very least the size of the
patches that you'd have to maintain separately should be substantially
reduced.

It seems that there is some convergence going on around the idea that GCC
would support a syntax similar to Altivec but in some senses more general,
but with at least one difference in that vector literals would be C99
style, plus possibly an optional alteration in preprocessing to allow
existing syntax to be handled.  I think that there's some jumping of the
gun going on: you're proposing solutions before the problem has been fully
defined.  What will the GCC syntax be (and what are the semantics)?  This
determines what kind of rewriting you have to do.  Also, is lexing alone
strong enough to do the conversion, or do you need parsing as well?  The
vector literals aren't regular expressions, since constant expressions are
allowed, but if all you need is the ability to count nesting depth in
parentheses this isn't so bad.

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

[Per Bothner]

Ziemowit Laski wrote:

 > I wouldn't mind COLLABORATING with someone on this (I don't think I
 > have sufficient cycles left in my day to go it alone).  But first
 > and foremost, I'd like to have some sort of a statement from the SC
 > specifying the technical parameters of an acceptable solution --
 > in other words, a guarantee that if a solution meeting those
 > criteria is created, it will be accepted.

Generally the SC defers to the maintainers, especially the more
experienced/senior maintainers - some of whom are SC members.

In any case I don't think either the SC or the experienced
maintainers can make much of a statement "specifying the
technical parameters of an acceptable solution", nor can we
make any "guarantee that if a solution meeting those criteria
is created, it will be accepted". Sorry.  Instead, you will
have to make a proposal on this mailing list, and achieve a
more-or-less consensus that what you're proposing is
sufficiently useful and implementable that it makes up for
any extra maintainance or compile-time performance problems.

 > No more Pascal string work from me. :) :)

My take on that was that Apple gave up just a little too
easily on that, and that we were close to accepting the
\p extension.  At least I was leaning in favor of it.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

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

[Ziemowit Laski]

On Wednesday, November 28, 2001, at 12:36 , Per Bothner wrote:

> In any case I don't think either the SC or the experienced
> maintainers can make much of a statement "specifying the
> technical parameters of an acceptable solution", nor can we
> make any "guarantee that if a solution meeting those criteria

By "technical parameters" I meant _requirements_ that would be arrived
at through iterative discussion on this list.  Since we're talking
about a compiler, requirements would naturally be technical in nature.

> is created, it will be accepted". Sorry.  Instead, you will
> have to make a proposal on this mailing list, and achieve a
> more-or-less consensus that what you're proposing is

In that case, include me out. :)

> > No more Pascal string work from me. :) :)
>
> My take on that was that Apple gave up just a little too
> easily on that, and that we were close to accepting the
> \p extension.  At least I was leaning in favor of it.

Phrases like "close to accepting" or "leaning in favor"
(or, just now, "more-or-less consensus") are too vague for me to
rely on when devoting my time (and my employer's money!) to
a project.  What I was looking for was a monosyllabic "yes" or
"no," which I never got.

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

[David Edelsohn]

>>>>> Ziemowit Laski writes:

Ziemowit> Phrases like "close to accepting" or "leaning in favor"
Ziemowit> (or, just now, "more-or-less consensus") are too vague for me to
Ziemowit> rely on when devoting my time (and my employer's money!) to
Ziemowit> a project.  What I was looking for was a monosyllabic "yes" or
Ziemowit> "no," which I never got.

	Sorry, but that is how Free Software Development works.  We work
to reach consensus among interested parties and maintainers. 

David

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

[Ziemowit Laski]

On Wednesday, November 28, 2001, at 06:29 , David Edelsohn wrote:

>>>>>> Ziemowit Laski writes:
>
> Ziemowit> Phrases like "close to accepting" or "leaning in favor"
> Ziemowit> (or, just now, "more-or-less consensus") are too vague for me 
> to
> Ziemowit> rely on when devoting my time (and my employer's money!) to
> Ziemowit> a project.  What I was looking for was a monosyllabic "yes" or
> Ziemowit> "no," which I never got.
>
> 	Sorry, but that is how Free Software Development works.  We work
> to reach consensus among interested parties and maintainers.

Trouble is, it is very hard to tell when you've reached it. :)

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

[Ziemowit Laski]

On Wednesday, November 28, 2001, at 06:29 , David Edelsohn wrote:

>>>>>> Ziemowit Laski writes:
>
> Ziemowit> Phrases like "close to accepting" or "leaning in favor"
> Ziemowit> (or, just now, "more-or-less consensus") are too vague for me 
> to
> Ziemowit> rely on when devoting my time (and my employer's money!) to
> Ziemowit> a project.  What I was looking for was a monosyllabic "yes" or
> Ziemowit> "no," which I never got.
>
> 	Sorry, but that is how Free Software Development works.  We work
> to reach consensus among interested parties and maintainers.

Trouble is, it is very hard to tell when you've reached it. :)

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

[David Edelsohn]

>>>>> Ziemowit Laski writes:

Ziemowit> Phrases like "close to accepting" or "leaning in favor"
Ziemowit> (or, just now, "more-or-less consensus") are too vague for me to
Ziemowit> rely on when devoting my time (and my employer's money!) to
Ziemowit> a project.  What I was looking for was a monosyllabic "yes" or
Ziemowit> "no," which I never got.

	Sorry, but that is how Free Software Development works.  We work
to reach consensus among interested parties and maintainers. 

David

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

[Ziemowit Laski]

On Wednesday, November 28, 2001, at 12:36 , Per Bothner wrote:

> In any case I don't think either the SC or the experienced
> maintainers can make much of a statement "specifying the
> technical parameters of an acceptable solution", nor can we
> make any "guarantee that if a solution meeting those criteria

By "technical parameters" I meant _requirements_ that would be arrived
at through iterative discussion on this list.  Since we're talking
about a compiler, requirements would naturally be technical in nature.

> is created, it will be accepted". Sorry.  Instead, you will
> have to make a proposal on this mailing list, and achieve a
> more-or-less consensus that what you're proposing is

In that case, include me out. :)

> > No more Pascal string work from me. :) :)
>
> My take on that was that Apple gave up just a little too
> easily on that, and that we were close to accepting the
> \p extension.  At least I was leaning in favor of it.

Phrases like "close to accepting" or "leaning in favor"
(or, just now, "more-or-less consensus") are too vague for me to
rely on when devoting my time (and my employer's money!) to
a project.  What I was looking for was a monosyllabic "yes" or
"no," which I never got.

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

[Per Bothner]

Ziemowit Laski wrote:

 > I wouldn't mind COLLABORATING with someone on this (I don't think I
 > have sufficient cycles left in my day to go it alone).  But first
 > and foremost, I'd like to have some sort of a statement from the SC
 > specifying the technical parameters of an acceptable solution --
 > in other words, a guarantee that if a solution meeting those
 > criteria is created, it will be accepted.

Generally the SC defers to the maintainers, especially the more
experienced/senior maintainers - some of whom are SC members.

In any case I don't think either the SC or the experienced
maintainers can make much of a statement "specifying the
technical parameters of an acceptable solution", nor can we
make any "guarantee that if a solution meeting those criteria
is created, it will be accepted". Sorry.  Instead, you will
have to make a proposal on this mailing list, and achieve a
more-or-less consensus that what you're proposing is
sufficiently useful and implementable that it makes up for
any extra maintainance or compile-time performance problems.

 > No more Pascal string work from me. :) :)

My take on that was that Apple gave up just a little too
easily on that, and that we were close to accepting the
\p extension.  At least I was leaning in favor of it.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

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

[Ziemowit Laski]

On Wednesday, November 28, 2001, at 07:36 , Aldy Hernandez wrote:

>>>>>> "Ziemowit" == Ziemowit Laski <zlaski@apple.com> writes:
>
>> On Tuesday, November 27, 2001, at 06:23 , Aldy Hernandez wrote:
>
>>> I've actually thought about implementing generic front end extension
>>> support to gcc for this kind of nonsense.  Sort of like a preprocessor
>>> that runs after the actual C preprocessor-- massages the output in any
>>> way it sees fit, and feeds its output to the lexical analyzer.
>>>
>>> This way if someone wants to implement some brain dead front end
>>> extension widely used somewhere else, it could be a plugin-- and we
>>> could offer a whole slew of plugins in the future (altivec plugins,
>>> msoft inline assembly plugin, etc etc).
>>>
>>> That sounds like a good project :)
>
>> Well, it definitely sounds interesting!  Tell me more. :) :)
>
> simple, it just reads the output from CPP, manipulates the strings,
> and, feeds it's output to the lexer.

Interesting idea.  I was thinking along the lines of putting this
functionality into the back-end of CPP itself (so that you can use -E
to see how the code is being rewritten), and instead of dealing with
raw source lines operate on the resulting token stream (i.e., rearrange,
insert, remove tokens) before passing it out.  But I think we're 
basically
on the same page.

I wouldn't mind COLLABORATING with someone on this (I don't think I have
sufficient cycles left in my day to go it alone).  But first and 
foremost,
I'd like to have some sort of a statement from the SC specifying the
technical parameters of an acceptable solution -- in other words, a
guarantee that if a solution meeting those criteria is created, it will
be accepted.  No more Pascal string work from me. :) :)

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

[Aldy Hernandez]

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

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

 >> I've actually thought about implementing generic front end extension
 >> support to gcc for this kind of nonsense.  Sort of like a preprocessor
 >> that runs after the actual C preprocessor-- massages the output in any
 >> way it sees fit, and feeds its output to the lexical analyzer.
 >> 
 >> This way if someone wants to implement some brain dead front end
 >> extension widely used somewhere else, it could be a plugin-- and we
 >> could offer a whole slew of plugins in the future (altivec plugins,
 >> msoft inline assembly plugin, etc etc).
 >> 
 >> That sounds like a good project :)

 > Well, it definitely sounds interesting!  Tell me more. :) :)

simple, it just reads the output from CPP, manipulates the strings,
and, feeds it's output to the lexer.

You would register your extension before the lexer starts doing it's
thing.

Code is worth a thousand words:

        typedef char * (*fe_extension)(char *);

        char *
        altivec_extension (char *line)
        {
                char *p;

                p = altivec_massage (line);
                return p;
        }

        void
        lexer_setup()
        {
                ...
                if (TARGET_ALTIVEC)
                        register_fe_extension (altivec_extension);
                ...
        }

        int
        lex ()
        {
                ...
                c = extended_lexer ();
                ...
        }

        int
        extended_lexer ()
        {
                char *p;
                static char *q;
                int i;

                if (!q || !*q) {
                        p = read_next_line ();

                        /* Massage the current line with all the FE
                           extensions applicable.  */
                        for (i = 0; i < total_fe_extensions; i++)
                                q = (fe_extension[i])(p);
                }

                return *q++;
        }

that's the general idea.  The assumption is that most FE extensions
can be translated into something saner involving intrinsics or
something more gcc-able.  The goal is not to provide an entire parser
in each extension, but to come up with a set of heuristics that will
do string replacements.

In cases where we need context, the extension could keep a few state
variables to know what it's seen so far and what it expects.  Nothing
too complicated, just to get the job done.

One simple example would be for the altivec extension to recognize

        ...(1,2,3,4)

in an initializer and merely replace it with {}'s.

...and I'm taking volunteers for this project :)

Aldy

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

[Ziemowit Laski]

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

> I've actually thought about implementing generic front end extension
> support to gcc for this kind of nonsense.  Sort of like a preprocessor
> that runs after the actual C preprocessor-- massages the output in any
> way it sees fit, and feeds its output to the lexical analyzer.
>
> This way if someone wants to implement some brain dead front end
> extension widely used somewhere else, it could be a plugin-- and we
> could offer a whole slew of plugins in the future (altivec plugins,
> msoft inline assembly plugin, etc etc).
>
> That sounds like a good project :)

Well, it definitely sounds interesting!  Tell me more. :) :)
--------------------------------------------------------------
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

[Devang Patel]

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

>>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
>
>>> Consider a preprocessor that takes current Altivec C code and produces
>>> either standard or extended C code (GNU extensions).  If adopting the
>>> existing Altivec syntax is too painful, a second choice might be to 
>>> figure
>>> out syntax choices that would make such a preprocessor very easy to 
>>> write.
>>> Then we don't have to ask existing users to rewrite their code.
>
>> Yup, I thought about this too.  It's plausible, but a pretty 
>> substantial
>> effort, and not easy to do robustly with the tools we've got.
>
> I've actually thought about implementing generic front end extension
> support to gcc for this kind of nonsense.  Sort of like a preprocessor
> ...
> what do y'all think?

- One very big disadvantage of GCC, compared to other compilers, is
   compile time speed. I think it may not be a good idea to eat millions 
of
   tokens just to take care of couple of tokens. Every machine cycle 
counts.

- It may open pandora's box for many unnecessary extensions and put
   GCC users in difficult situation when these extensions are not carry
   forwarded.

Instead of extra preprocessor , It's would be nice to have good  plug-in 
architecture
in GCC front end (like GCC back end architecture)

- Plus, this kind of extension means Altivec will always remains outside 
of main
   GCC front end engine. And it may not be a good idea in long run, 
because
   -- Any major redesign/improvement of front end will not consider 
Altivec during
       design and will require extra support to keep Altivec extension up 
to date.
   -- Any future C-based language standard update may introduce new things
        which may collide with spec supported by such Altivec extension. 
This
        can create lots of problems for Altivec users as well as GCC 
developers.
        It is better to accept clear set of Altivec specs as part of GCC 
front end so that
        GCC can raise hands against such future collisions. (Which means, 
this
        may be the time two clean up any ambiguity in Altivec spec, if 
there is any, as
        far as GCC is concerned)

my thoughts,

Devang

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

[Devang Patel]

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

>>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
>
>>> Consider a preprocessor that takes current Altivec C code and produces
>>> either standard or extended C code (GNU extensions).  If adopting the
>>> existing Altivec syntax is too painful, a second choice might be to 
>>> figure
>>> out syntax choices that would make such a preprocessor very easy to 
>>> write.
>>> Then we don't have to ask existing users to rewrite their code.
>
>> Yup, I thought about this too.  It's plausible, but a pretty 
>> substantial
>> effort, and not easy to do robustly with the tools we've got.
>
> I've actually thought about implementing generic front end extension
> support to gcc for this kind of nonsense.  Sort of like a preprocessor
> ...
> what do y'all think?

- One very big disadvantage of GCC, compared to other compilers, is
   compile time speed. I think it may not be a good idea to eat millions 
of
   tokens just to take care of couple of tokens. Every machine cycle 
counts.

- It may open pandora's box for many unnecessary extensions and put
   GCC users in difficult situation when these extensions are not carry
   forwarded.

Instead of extra preprocessor , It's would be nice to have good  plug-in 
architecture
in GCC front end (like GCC back end architecture)

- Plus, this kind of extension means Altivec will always remains outside 
of main
   GCC front end engine. And it may not be a good idea in long run, 
because
   -- Any major redesign/improvement of front end will not consider 
Altivec during
       design and will require extra support to keep Altivec extension up 
to date.
   -- Any future C-based language standard update may introduce new things
        which may collide with spec supported by such Altivec extension. 
This
        can create lots of problems for Altivec users as well as GCC 
developers.
        It is better to accept clear set of Altivec specs as part of GCC 
front end so that
        GCC can raise hands against such future collisions. (Which means, 
this
        may be the time two clean up any ambiguity in Altivec spec, if 
there is any, as
        far as GCC is concerned)

my thoughts,

Devang

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

[Aldy Hernandez]

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

 >> Consider a preprocessor that takes current Altivec C code and produces
 >> either standard or extended C code (GNU extensions).  If adopting the
 >> existing Altivec syntax is too painful, a second choice might be to figure
 >> out syntax choices that would make such a preprocessor very easy to write.
 >> Then we don't have to ask existing users to rewrite their code.

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

I've actually thought about implementing generic front end extension
support to gcc for this kind of nonsense.  Sort of like a preprocessor
that runs after the actual C preprocessor-- massages the output in any
way it sees fit, and feeds its output to the lexical analyzer.

This way if someone wants to implement some brain dead front end
extension widely used somewhere else, it could be a plugin-- and we
could offer a whole slew of plugins in the future (altivec plugins,
msoft inline assembly plugin, etc etc).

That sounds like a good project :)

what do y'all think?

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

[Mark Mitchell]

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

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

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

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

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

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

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

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

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

[Alex Rosenberg]

(Sorry for the late response...)

on 11/27/01 3:26 PM, Mark Mitchell at mark@codesourcery.com wrote:

> --On Tuesday, November 27, 2001 02:53:26 PM -0800 Joe Buck
> <jbuck@synopsys.COM> wrote:
> 
>> Mark writes:
>>> Concretely, the Altivec specification allows "vector" to be either a
>>> macro, or a context-sensitive keyword.  The latter is a much better
>>> choice, and it is the one we should adopt in GCC.  It will be far
>>> less intrusive.
>> 
>> Allowing "vector" to be a macro would be completely unacceptable, because
>> people will mix C and C++ code.
> 
> The Altivec specification says that __vector is a keyword.  It says that
> vector can be either a macro or a context-sensitive keyword.  If it
> is a macro you are explicitly allowed to #undef it.
> 
> So, you can use __vector in C or C++, with any Altivec compiler.  If
> you're using (Altivec) vector in C++ code, you're not writing
> portable code, even across Altivec implementations.
> 
> I don't know how many Altivec code authors know this, but we would
> certainly be within the letter of the law going this way, and it's
> (relatively) easy to implement, and far less horrid than a
> context-sensitive keyword.

I just wanted to point out that the AltiVec PIM "specification" contains
this macro allowance (2.2.1) as a concession to the former Metrowerks
engineer who was responsible for AltiVec support. The same is true of the
entire discussion of the optional <altivec.h> include file in 2.6. At that
time, he didn't understand Ira's explanations of "context-sensitive keyword"
(much as many on the gcc list seem to not understand it).

Shortly before MW shipped their first AltiVec support release, they switched
over to the context-sensitive "vector" method (2.2.2). Pretty much every
line of existing AltiVec code uses "vector" in this way.

It seems to me that a major problem with target-dependant front-end
extensions like this is that the front-ends are automatically built from a
grammar and installers aren't required to have those tools.

Would the new C++ front-end make this less difficult?

+------------------------------------------------------------+
| Alexander M. Rosenberg           <mailto:alexr@_spies.com> |
| Nobody cares what I say. Remove the underscore to mail me. |

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

[Mark Mitchell]

> Would the new C++ front-end make this less difficult?

Yes -- but we seem to have reached a good consensus on how to proceed
so we should proceed that way.

Thanks,

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

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

[Aldy Hernandez]

> Shortly before MW shipped their first AltiVec support release, they switched
> over to the context-sensitive "vector" method (2.2.2). Pretty much every
> line of existing AltiVec code uses "vector" in this way.
> 
> It seems to me that a major problem with target-dependant front-end
> extensions like this is that the front-ends are automatically built from a
> grammar and installers aren't required to have those tools.
> 
> Would the new C++ front-end make this less difficult?

the consensus on a least intrusive method, is to have "__vector" expand
to "__attribute__((vector_size(n))".  this way, no changes are needed to
the front end per se.  and yes, we will require you to include
<altivec.h>
> 
> +------------------------------------------------------------+
> | Alexander M. Rosenberg           <mailto:alexr@_spies.com> |
> | Nobody cares what I say. Remove the underscore to mail me. |
> 
-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

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

[Joe Buck]

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

Allowing "vector" to be a macro would be completely unacceptable, because
people will mix C and C++ code.

> Other things are more difficult.  Vector literals should just be
> C99 compound literals, but I'm not sure whether we can get away
> with changing that or not.

A modest proposal:

Consider a preprocessor that takes current Altivec C code and produces
either standard or extended C code (GNU extensions).  If adopting the
existing Altivec syntax is too painful, a second choice might be to figure
out syntax choices that would make such a preprocessor very easy to write.
Then we don't have to ask existing users to rewrite their code.

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

[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 foraltivec)

[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)

[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

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

front end changes for altivec

[Aldy Hernandez]

hi guys!

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.

i would really hate to perpetually maintain a set of front end patches,
so i'm wondering if there's any sensible, least intrusive way to
implement these changes and have them incorporated into mainline gcc.

i am not a fan at all of these front end changes, but the specs are
already out there and a variety of other compilers already conform to
them.

the changes are very few and are outlined below:

    __vector keyword:
    
    	__vector int	=> mode(V4SI)
    	__vector char	=> mode(V16QI)
    	etc etc
    	
        (it could really be __altivec_vector for all i care because the
        specs allow part of the definitions to be in a separate include
        file (altivec.h?), so we could have
        
        #define __vector __altivec_vector
        
	   ...in a separate file.
    
    vector constant initializers:
    
    	__vector int foo = (5, 8, 3, 2);
    
    (yes, those are parentheses, not curlys :-()
    
i'd first like to discuss the feasability of incorporating these changes
with irritating the least amount of people, and having them accepted.

failing this, i have a few thoughts on extending the lexical analyzer to
include some sort of front end plugin support.-- but i'd like to discuss
the previous option first.

bomb away.

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

Re: front end changes for altivec

[mike stump]

> Date: Tue, 27 Nov 2001 14:50:22 -0800
> From: Stan Shebs <shebs@apple.com>
> To: Richard Henderson <rth@redhat.com>

> You mean like how we don't have machine-dependent sizes for int
> and long int?

If in the end we have a portable thing that users can use in a fairly
simple and straight forward way, that allows them to switch from a mmx
machine to an sse machine, to an sse2 machine, to a ...  machine, we
win.  A good design is also forward compatible with strange hardware
that might come up in the future, or strange new operations...

On a good number of machines, almost all that matter, int is 32 bits,
long int is 32 bits.  I can't help but wonder if C would have been a
better standard, if they had just outright said, ints are 32 bits,
period.  It would have removed one major source of confusion and
increased (in a theoretical sense only) the portability of user code.

I can't help but think that code that does:

vector<int[4]> a, b;

int foo() { a += b; }

is intrinsically better than

vector<int> a, b;

int foo() { a += b; }

We can engineer gcc to have the first work on all machines, quickly on
some, `normal' speed on the rest.  C++ people, don't let the second
confuse you into thinking of std::vector, it is totally different.
Think gnu::gcc::vector.

In reading code like:

vector<int[32]> a, b;

int foo() { a += b; }

I can say, wow, someone has an arm core with a beefy vector unit
attached on an ASIC and I bet this puppy smokes.  I can also know that
I could compile it up as portable C code, and it would run on anything
GNU C supports, though, I might want a faster box in the end (bearing
in mind that sizeof(int)==4).

Re: front end changes for altivec

[mike stump]

> Date: Tue, 27 Nov 2001 14:50:22 -0800
> From: Stan Shebs <shebs@apple.com>
> To: Richard Henderson <rth@redhat.com>

> You mean like how we don't have machine-dependent sizes for int
> and long int?

If in the end we have a portable thing that users can use in a fairly
simple and straight forward way, that allows them to switch from a mmx
machine to an sse machine, to an sse2 machine, to a ...  machine, we
win.  A good design is also forward compatible with strange hardware
that might come up in the future, or strange new operations...

On a good number of machines, almost all that matter, int is 32 bits,
long int is 32 bits.  I can't help but wonder if C would have been a
better standard, if they had just outright said, ints are 32 bits,
period.  It would have removed one major source of confusion and
increased (in a theoretical sense only) the portability of user code.

I can't help but think that code that does:

vector<int[4]> a, b;

int foo() { a += b; }

is intrinsically better than

vector<int> a, b;

int foo() { a += b; }

We can engineer gcc to have the first work on all machines, quickly on
some, `normal' speed on the rest.  C++ people, don't let the second
confuse you into thinking of std::vector, it is totally different.
Think gnu::gcc::vector.

In reading code like:

vector<int[32]> a, b;

int foo() { a += b; }

I can say, wow, someone has an arm core with a beefy vector unit
attached on an ASIC and I bet this puppy smokes.  I can also know that
I could compile it up as portable C code, and it would run on anything
GNU C supports, though, I might want a faster box in the end (bearing
in mind that sizeof(int)==4).