* front end changes for altivec @ 2001-11-16 9:10 Aldy Hernandez 2001-11-16 9:25 ` Andreas Jaeger ` (2 more replies) 0 siblings, 3 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-16 9:10 UTC (permalink / raw) To: gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-16 9:10 front end changes for altivec Aldy Hernandez @ 2001-11-16 9:25 ` Andreas Jaeger 2001-11-26 2:55 ` Andreas Jaeger 2001-11-18 3:56 ` Joseph S. Myers 2001-11-26 2:51 ` Aldy Hernandez 2 siblings, 1 reply; 229+ messages in thread From: Andreas Jaeger @ 2001-11-16 9:25 UTC (permalink / raw) To: Aldy Hernandez; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-16 9:25 ` Andreas Jaeger @ 2001-11-26 2:55 ` Andreas Jaeger 0 siblings, 0 replies; 229+ messages in thread From: Andreas Jaeger @ 2001-11-26 2:55 UTC (permalink / raw) To: Aldy Hernandez; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-16 9:10 front end changes for altivec Aldy Hernandez 2001-11-16 9:25 ` Andreas Jaeger @ 2001-11-18 3:56 ` Joseph S. Myers 2001-11-18 4:24 ` Aldy Hernandez ` (2 more replies) 2001-11-26 2:51 ` Aldy Hernandez 2 siblings, 3 replies; 229+ messages in thread From: Joseph S. Myers @ 2001-11-18 3:56 UTC (permalink / raw) To: Aldy Hernandez; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-18 3:56 ` Joseph S. Myers @ 2001-11-18 4:24 ` Aldy Hernandez 2001-11-18 5:09 ` Joseph S. Myers 2001-11-26 16:39 ` Aldy Hernandez 2001-11-18 6:40 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski 2001-11-26 15:45 ` front end changes for altivec Joseph S. Myers 2 siblings, 2 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-18 4:24 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Aldy Hernandez, gcc > > __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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-18 4:24 ` Aldy Hernandez @ 2001-11-18 5:09 ` Joseph S. Myers 2001-11-18 6:10 ` Aldy Hernandez ` (2 more replies) 2001-11-26 16:39 ` Aldy Hernandez 1 sibling, 3 replies; 229+ messages in thread From: Joseph S. Myers @ 2001-11-18 5:09 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Aldy Hernandez, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-18 5:09 ` Joseph S. Myers @ 2001-11-18 6:10 ` Aldy Hernandez 2001-11-18 7:35 ` Richard Henderson 2001-11-26 18:19 ` Aldy Hernandez 2001-11-18 12:41 ` Aldy Hernandez 2001-11-26 17:04 ` Joseph S. Myers 2 siblings, 2 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-18 6:10 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Aldy Hernandez, Aldy Hernandez, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-18 6:10 ` Aldy Hernandez @ 2001-11-18 7:35 ` Richard Henderson 2001-11-26 19:50 ` Richard Henderson 2001-11-26 18:19 ` Aldy Hernandez 1 sibling, 1 reply; 229+ messages in thread From: Richard Henderson @ 2001-11-18 7:35 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Joseph S. Myers, Aldy Hernandez, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-18 7:35 ` Richard Henderson @ 2001-11-26 19:50 ` Richard Henderson 0 siblings, 0 replies; 229+ messages in thread From: Richard Henderson @ 2001-11-26 19:50 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Joseph S. Myers, Aldy Hernandez, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-18 6:10 ` Aldy Hernandez 2001-11-18 7:35 ` Richard Henderson @ 2001-11-26 18:19 ` Aldy Hernandez 1 sibling, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-26 18:19 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Aldy Hernandez, Aldy Hernandez, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-18 5:09 ` Joseph S. Myers 2001-11-18 6:10 ` Aldy Hernandez @ 2001-11-18 12:41 ` Aldy Hernandez 2001-11-18 13:38 ` Andreas Jaeger ` (2 more replies) 2001-11-26 17:04 ` Joseph S. Myers 2 siblings, 3 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-18 12:41 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc > 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-18 12:41 ` Aldy Hernandez @ 2001-11-18 13:38 ` Andreas Jaeger 2001-11-18 15:32 ` Aldy Hernandez 2001-11-27 7:50 ` Andreas Jaeger 2001-11-19 8:02 ` Richard Henderson 2001-11-27 7:24 ` Aldy Hernandez 2 siblings, 2 replies; 229+ messages in thread From: Andreas Jaeger @ 2001-11-18 13:38 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-18 13:38 ` Andreas Jaeger @ 2001-11-18 15:32 ` Aldy Hernandez 2001-11-18 16:49 ` Bernd Schmidt 2001-11-27 7:55 ` Aldy Hernandez 2001-11-27 7:50 ` Andreas Jaeger 1 sibling, 2 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-18 15:32 UTC (permalink / raw) To: Andreas Jaeger; +Cc: Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-18 15:32 ` Aldy Hernandez @ 2001-11-18 16:49 ` Bernd Schmidt 2001-11-18 17:06 ` Aldy Hernandez 2001-11-27 8:00 ` Bernd Schmidt 2001-11-27 7:55 ` Aldy Hernandez 1 sibling, 2 replies; 229+ messages in thread From: Bernd Schmidt @ 2001-11-18 16:49 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Andreas Jaeger, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-18 16:49 ` Bernd Schmidt @ 2001-11-18 17:06 ` Aldy Hernandez 2001-11-27 8:29 ` Aldy Hernandez 2001-11-27 8:00 ` Bernd Schmidt 1 sibling, 1 reply; 229+ messages in thread From: Aldy Hernandez @ 2001-11-18 17:06 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Andreas Jaeger, Joseph S. Myers, gcc > > > 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-18 17:06 ` Aldy Hernandez @ 2001-11-27 8:29 ` Aldy Hernandez 0 siblings, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-27 8:29 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Andreas Jaeger, Joseph S. Myers, gcc > > > 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-18 16:49 ` Bernd Schmidt 2001-11-18 17:06 ` Aldy Hernandez @ 2001-11-27 8:00 ` Bernd Schmidt 1 sibling, 0 replies; 229+ messages in thread From: Bernd Schmidt @ 2001-11-27 8:00 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Andreas Jaeger, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-18 15:32 ` Aldy Hernandez 2001-11-18 16:49 ` Bernd Schmidt @ 2001-11-27 7:55 ` Aldy Hernandez 1 sibling, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-27 7:55 UTC (permalink / raw) To: Andreas Jaeger; +Cc: Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-18 13:38 ` Andreas Jaeger 2001-11-18 15:32 ` Aldy Hernandez @ 2001-11-27 7:50 ` Andreas Jaeger 1 sibling, 0 replies; 229+ messages in thread From: Andreas Jaeger @ 2001-11-27 7:50 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-18 12:41 ` Aldy Hernandez 2001-11-18 13:38 ` Andreas Jaeger @ 2001-11-19 8:02 ` Richard Henderson 2001-11-19 8:35 ` Aldy Hernandez 2001-11-27 13:40 ` Richard Henderson 2001-11-27 7:24 ` Aldy Hernandez 2 siblings, 2 replies; 229+ messages in thread From: Richard Henderson @ 2001-11-19 8:02 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Joseph S. Myers, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 8:02 ` Richard Henderson @ 2001-11-19 8:35 ` Aldy Hernandez 2001-11-19 9:19 ` Richard Henderson 2001-11-27 13:52 ` Aldy Hernandez 2001-11-27 13:40 ` Richard Henderson 1 sibling, 2 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-19 8:35 UTC (permalink / raw) To: Richard Henderson; +Cc: Joseph S. Myers, gcc > 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 8:35 ` Aldy Hernandez @ 2001-11-19 9:19 ` Richard Henderson 2001-11-19 11:51 ` Stan Shebs ` (2 more replies) 2001-11-27 13:52 ` Aldy Hernandez 1 sibling, 3 replies; 229+ messages in thread From: Richard Henderson @ 2001-11-19 9:19 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Joseph S. Myers, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 9:19 ` Richard Henderson @ 2001-11-19 11:51 ` Stan Shebs 2001-11-19 13:41 ` Richard Henderson 2001-11-27 14:50 ` Stan Shebs 2001-11-19 15:25 ` Aldy Hernandez 2001-11-27 14:01 ` Richard Henderson 2 siblings, 2 replies; 229+ messages in thread From: Stan Shebs @ 2001-11-19 11:51 UTC (permalink / raw) To: Richard Henderson; +Cc: Aldy Hernandez, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 11:51 ` Stan Shebs @ 2001-11-19 13:41 ` Richard Henderson 2001-11-19 16:13 ` Aldy Hernandez 2001-11-27 15:16 ` Richard Henderson 2001-11-27 14:50 ` Stan Shebs 1 sibling, 2 replies; 229+ messages in thread From: Richard Henderson @ 2001-11-19 13:41 UTC (permalink / raw) To: Stan Shebs; +Cc: Aldy Hernandez, Joseph S. Myers, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 13:41 ` Richard Henderson @ 2001-11-19 16:13 ` Aldy Hernandez 2001-11-19 17:51 ` Richard Henderson 2001-11-27 16:57 ` Aldy Hernandez 2001-11-27 15:16 ` Richard Henderson 1 sibling, 2 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-19 16:13 UTC (permalink / raw) To: Richard Henderson; +Cc: Stan Shebs, Joseph S. Myers, gcc > > 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 16:13 ` Aldy Hernandez @ 2001-11-19 17:51 ` Richard Henderson 2001-11-19 19:15 ` Aldy Hernandez ` (2 more replies) 2001-11-27 16:57 ` Aldy Hernandez 1 sibling, 3 replies; 229+ messages in thread From: Richard Henderson @ 2001-11-19 17:51 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Stan Shebs, Joseph S. Myers, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 17:51 ` Richard Henderson @ 2001-11-19 19:15 ` Aldy Hernandez 2001-11-19 20:50 ` Richard Henderson 2001-11-27 17:10 ` Aldy Hernandez 2001-11-21 13:08 ` Alexandre Oliva 2001-11-27 17:03 ` Richard Henderson 2 siblings, 2 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-19 19:15 UTC (permalink / raw) To: Richard Henderson; +Cc: Stan Shebs, Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 19:15 ` Aldy Hernandez @ 2001-11-19 20:50 ` Richard Henderson 2001-11-27 17:14 ` Richard Henderson 2001-11-27 17:10 ` Aldy Hernandez 1 sibling, 1 reply; 229+ messages in thread From: Richard Henderson @ 2001-11-19 20:50 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Stan Shebs, Joseph S. Myers, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 20:50 ` Richard Henderson @ 2001-11-27 17:14 ` Richard Henderson 0 siblings, 0 replies; 229+ messages in thread From: Richard Henderson @ 2001-11-27 17:14 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Stan Shebs, Joseph S. Myers, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 19:15 ` Aldy Hernandez 2001-11-19 20:50 ` Richard Henderson @ 2001-11-27 17:10 ` Aldy Hernandez 1 sibling, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-27 17:10 UTC (permalink / raw) To: Richard Henderson; +Cc: Stan Shebs, Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 17:51 ` Richard Henderson 2001-11-19 19:15 ` Aldy Hernandez @ 2001-11-21 13:08 ` Alexandre Oliva 2001-11-21 13:12 ` Daniel Berlin ` (2 more replies) 2001-11-27 17:03 ` Richard Henderson 2 siblings, 3 replies; 229+ messages in thread From: Alexandre Oliva @ 2001-11-21 13:08 UTC (permalink / raw) To: Richard Henderson; +Cc: Aldy Hernandez, Stan Shebs, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-21 13:08 ` Alexandre Oliva @ 2001-11-21 13:12 ` Daniel Berlin 2001-11-21 13:29 ` Alexandre Oliva ` (2 more replies) 2001-11-21 13:24 ` Per Bothner 2001-11-28 21:07 ` Alexandre Oliva 2 siblings, 3 replies; 229+ messages in thread From: Daniel Berlin @ 2001-11-21 13:12 UTC (permalink / raw) To: Alexandre Oliva Cc: Richard Henderson, Aldy Hernandez, Stan Shebs, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-21 13:12 ` Daniel Berlin @ 2001-11-21 13:29 ` Alexandre Oliva 2001-11-21 13:31 ` Daniel Berlin 2001-11-28 22:34 ` Alexandre Oliva 2001-11-21 13:33 ` Richard Henderson 2001-11-28 22:21 ` Daniel Berlin 2 siblings, 2 replies; 229+ messages in thread From: Alexandre Oliva @ 2001-11-21 13:29 UTC (permalink / raw) To: Daniel Berlin Cc: Richard Henderson, Aldy Hernandez, Stan Shebs, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-21 13:29 ` Alexandre Oliva @ 2001-11-21 13:31 ` Daniel Berlin 2001-11-21 13:41 ` Jack Lloyd 2001-11-28 23:00 ` Daniel Berlin 2001-11-28 22:34 ` Alexandre Oliva 1 sibling, 2 replies; 229+ messages in thread From: Daniel Berlin @ 2001-11-21 13:31 UTC (permalink / raw) To: Alexandre Oliva Cc: Richard Henderson, Aldy Hernandez, Stan Shebs, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-21 13:31 ` Daniel Berlin @ 2001-11-21 13:41 ` Jack Lloyd 2001-11-28 23:44 ` Jack Lloyd 2001-11-28 23:00 ` Daniel Berlin 1 sibling, 1 reply; 229+ messages in thread From: Jack Lloyd @ 2001-11-21 13:41 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-21 13:41 ` Jack Lloyd @ 2001-11-28 23:44 ` Jack Lloyd 0 siblings, 0 replies; 229+ messages in thread From: Jack Lloyd @ 2001-11-28 23:44 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-21 13:31 ` Daniel Berlin 2001-11-21 13:41 ` Jack Lloyd @ 2001-11-28 23:00 ` Daniel Berlin 1 sibling, 0 replies; 229+ messages in thread From: Daniel Berlin @ 2001-11-28 23:00 UTC (permalink / raw) To: Alexandre Oliva Cc: Richard Henderson, Aldy Hernandez, Stan Shebs, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-21 13:29 ` Alexandre Oliva 2001-11-21 13:31 ` Daniel Berlin @ 2001-11-28 22:34 ` Alexandre Oliva 1 sibling, 0 replies; 229+ messages in thread From: Alexandre Oliva @ 2001-11-28 22:34 UTC (permalink / raw) To: Daniel Berlin Cc: Richard Henderson, Aldy Hernandez, Stan Shebs, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-21 13:12 ` Daniel Berlin 2001-11-21 13:29 ` Alexandre Oliva @ 2001-11-21 13:33 ` Richard Henderson 2001-11-21 13:49 ` Daniel Berlin 2001-11-28 23:16 ` Richard Henderson 2001-11-28 22:21 ` Daniel Berlin 2 siblings, 2 replies; 229+ messages in thread From: Richard Henderson @ 2001-11-21 13:33 UTC (permalink / raw) To: Daniel Berlin Cc: Alexandre Oliva, Aldy Hernandez, Stan Shebs, Joseph S. Myers, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-21 13:33 ` Richard Henderson @ 2001-11-21 13:49 ` Daniel Berlin 2001-11-29 4:45 ` Daniel Berlin 2001-11-28 23:16 ` Richard Henderson 1 sibling, 1 reply; 229+ messages in thread From: Daniel Berlin @ 2001-11-21 13:49 UTC (permalink / raw) To: Richard Henderson Cc: Alexandre Oliva, Aldy Hernandez, Stan Shebs, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-21 13:49 ` Daniel Berlin @ 2001-11-29 4:45 ` Daniel Berlin 0 siblings, 0 replies; 229+ messages in thread From: Daniel Berlin @ 2001-11-29 4:45 UTC (permalink / raw) To: Richard Henderson Cc: Alexandre Oliva, Aldy Hernandez, Stan Shebs, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-21 13:33 ` Richard Henderson 2001-11-21 13:49 ` Daniel Berlin @ 2001-11-28 23:16 ` Richard Henderson 1 sibling, 0 replies; 229+ messages in thread From: Richard Henderson @ 2001-11-28 23:16 UTC (permalink / raw) To: Daniel Berlin Cc: Alexandre Oliva, Aldy Hernandez, Stan Shebs, Joseph S. Myers, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-21 13:12 ` Daniel Berlin 2001-11-21 13:29 ` Alexandre Oliva 2001-11-21 13:33 ` Richard Henderson @ 2001-11-28 22:21 ` Daniel Berlin 2 siblings, 0 replies; 229+ messages in thread From: Daniel Berlin @ 2001-11-28 22:21 UTC (permalink / raw) To: Alexandre Oliva Cc: Richard Henderson, Aldy Hernandez, Stan Shebs, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-21 13:08 ` Alexandre Oliva 2001-11-21 13:12 ` Daniel Berlin @ 2001-11-21 13:24 ` Per Bothner 2001-11-28 22:25 ` Per Bothner 2001-11-28 21:07 ` Alexandre Oliva 2 siblings, 1 reply; 229+ messages in thread From: Per Bothner @ 2001-11-21 13:24 UTC (permalink / raw) To: Alexandre Oliva Cc: Richard Henderson, Aldy Hernandez, Stan Shebs, Joseph S. Myers, gcc 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/ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-21 13:24 ` Per Bothner @ 2001-11-28 22:25 ` Per Bothner 0 siblings, 0 replies; 229+ messages in thread From: Per Bothner @ 2001-11-28 22:25 UTC (permalink / raw) To: Alexandre Oliva Cc: Richard Henderson, Aldy Hernandez, Stan Shebs, Joseph S. Myers, gcc 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/ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-21 13:08 ` Alexandre Oliva 2001-11-21 13:12 ` Daniel Berlin 2001-11-21 13:24 ` Per Bothner @ 2001-11-28 21:07 ` Alexandre Oliva 2 siblings, 0 replies; 229+ messages in thread From: Alexandre Oliva @ 2001-11-28 21:07 UTC (permalink / raw) To: Richard Henderson; +Cc: Aldy Hernandez, Stan Shebs, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 17:51 ` Richard Henderson 2001-11-19 19:15 ` Aldy Hernandez 2001-11-21 13:08 ` Alexandre Oliva @ 2001-11-27 17:03 ` Richard Henderson 2 siblings, 0 replies; 229+ messages in thread From: Richard Henderson @ 2001-11-27 17:03 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Stan Shebs, Joseph S. Myers, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 16:13 ` Aldy Hernandez 2001-11-19 17:51 ` Richard Henderson @ 2001-11-27 16:57 ` Aldy Hernandez 1 sibling, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-27 16:57 UTC (permalink / raw) To: Richard Henderson; +Cc: Stan Shebs, Joseph S. Myers, gcc > > 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 13:41 ` Richard Henderson 2001-11-19 16:13 ` Aldy Hernandez @ 2001-11-27 15:16 ` Richard Henderson 1 sibling, 0 replies; 229+ messages in thread From: Richard Henderson @ 2001-11-27 15:16 UTC (permalink / raw) To: Stan Shebs; +Cc: Aldy Hernandez, Joseph S. Myers, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 11:51 ` Stan Shebs 2001-11-19 13:41 ` Richard Henderson @ 2001-11-27 14:50 ` Stan Shebs 1 sibling, 0 replies; 229+ messages in thread From: Stan Shebs @ 2001-11-27 14:50 UTC (permalink / raw) To: Richard Henderson; +Cc: Aldy Hernandez, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 9:19 ` Richard Henderson 2001-11-19 11:51 ` Stan Shebs @ 2001-11-19 15:25 ` Aldy Hernandez 2001-11-19 17:46 ` Richard Henderson 2001-11-27 16:50 ` Aldy Hernandez 2001-11-27 14:01 ` Richard Henderson 2 siblings, 2 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-19 15:25 UTC (permalink / raw) To: Richard Henderson; +Cc: Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 15:25 ` Aldy Hernandez @ 2001-11-19 17:46 ` Richard Henderson 2001-11-19 21:39 ` Aldy Hernandez 2001-11-27 17:02 ` Richard Henderson 2001-11-27 16:50 ` Aldy Hernandez 1 sibling, 2 replies; 229+ messages in thread From: Richard Henderson @ 2001-11-19 17:46 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Joseph S. Myers, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 17:46 ` Richard Henderson @ 2001-11-19 21:39 ` Aldy Hernandez 2001-11-20 1:05 ` Dale Johannesen ` (2 more replies) 2001-11-27 17:02 ` Richard Henderson 1 sibling, 3 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-19 21:39 UTC (permalink / raw) To: Richard Henderson; +Cc: Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 21:39 ` Aldy Hernandez @ 2001-11-20 1:05 ` Dale Johannesen 2001-11-20 2:23 ` Richard Henderson 2001-11-27 17:40 ` Dale Johannesen 2001-11-20 2:46 ` Richard Henderson 2001-11-27 17:24 ` Aldy Hernandez 2 siblings, 2 replies; 229+ messages in thread From: Dale Johannesen @ 2001-11-20 1:05 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Dale Johannesen, Richard Henderson, Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-20 1:05 ` Dale Johannesen @ 2001-11-20 2:23 ` Richard Henderson 2001-11-27 17:45 ` Richard Henderson 2001-11-27 17:40 ` Dale Johannesen 1 sibling, 1 reply; 229+ messages in thread From: Richard Henderson @ 2001-11-20 2:23 UTC (permalink / raw) To: Dale Johannesen; +Cc: Aldy Hernandez, Joseph S. Myers, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-20 2:23 ` Richard Henderson @ 2001-11-27 17:45 ` Richard Henderson 0 siblings, 0 replies; 229+ messages in thread From: Richard Henderson @ 2001-11-27 17:45 UTC (permalink / raw) To: Dale Johannesen; +Cc: Aldy Hernandez, Joseph S. Myers, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-20 1:05 ` Dale Johannesen 2001-11-20 2:23 ` Richard Henderson @ 2001-11-27 17:40 ` Dale Johannesen 1 sibling, 0 replies; 229+ messages in thread From: Dale Johannesen @ 2001-11-27 17:40 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Dale Johannesen, Richard Henderson, Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 21:39 ` Aldy Hernandez 2001-11-20 1:05 ` Dale Johannesen @ 2001-11-20 2:46 ` Richard Henderson 2001-11-20 2:56 ` front end changes for altivec-- conclusion Aldy Hernandez 2001-11-27 17:50 ` front end changes for altivec Richard Henderson 2001-11-27 17:24 ` Aldy Hernandez 2 siblings, 2 replies; 229+ messages in thread From: Richard Henderson @ 2001-11-20 2:46 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Joseph S. Myers, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec-- conclusion 2001-11-20 2:46 ` Richard Henderson @ 2001-11-20 2:56 ` Aldy Hernandez 2001-11-27 18:00 ` Aldy Hernandez 2001-11-27 17:50 ` front end changes for altivec Richard Henderson 1 sibling, 1 reply; 229+ messages in thread From: Aldy Hernandez @ 2001-11-20 2:56 UTC (permalink / raw) To: Richard Henderson; +Cc: Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec-- conclusion 2001-11-20 2:56 ` front end changes for altivec-- conclusion Aldy Hernandez @ 2001-11-27 18:00 ` Aldy Hernandez 0 siblings, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-27 18:00 UTC (permalink / raw) To: Richard Henderson; +Cc: Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-20 2:46 ` Richard Henderson 2001-11-20 2:56 ` front end changes for altivec-- conclusion Aldy Hernandez @ 2001-11-27 17:50 ` Richard Henderson 1 sibling, 0 replies; 229+ messages in thread From: Richard Henderson @ 2001-11-27 17:50 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Joseph S. Myers, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 21:39 ` Aldy Hernandez 2001-11-20 1:05 ` Dale Johannesen 2001-11-20 2:46 ` Richard Henderson @ 2001-11-27 17:24 ` Aldy Hernandez 2 siblings, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-27 17:24 UTC (permalink / raw) To: Richard Henderson; +Cc: Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 17:46 ` Richard Henderson 2001-11-19 21:39 ` Aldy Hernandez @ 2001-11-27 17:02 ` Richard Henderson 1 sibling, 0 replies; 229+ messages in thread From: Richard Henderson @ 2001-11-27 17:02 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Joseph S. Myers, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 15:25 ` Aldy Hernandez 2001-11-19 17:46 ` Richard Henderson @ 2001-11-27 16:50 ` Aldy Hernandez 1 sibling, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-27 16:50 UTC (permalink / raw) To: Richard Henderson; +Cc: Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 9:19 ` Richard Henderson 2001-11-19 11:51 ` Stan Shebs 2001-11-19 15:25 ` Aldy Hernandez @ 2001-11-27 14:01 ` Richard Henderson 2 siblings, 0 replies; 229+ messages in thread From: Richard Henderson @ 2001-11-27 14:01 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Joseph S. Myers, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 8:35 ` Aldy Hernandez 2001-11-19 9:19 ` Richard Henderson @ 2001-11-27 13:52 ` Aldy Hernandez 1 sibling, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-27 13:52 UTC (permalink / raw) To: Richard Henderson; +Cc: Joseph S. Myers, gcc > 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-19 8:02 ` Richard Henderson 2001-11-19 8:35 ` Aldy Hernandez @ 2001-11-27 13:40 ` Richard Henderson 1 sibling, 0 replies; 229+ messages in thread From: Richard Henderson @ 2001-11-27 13:40 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Joseph S. Myers, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-18 12:41 ` Aldy Hernandez 2001-11-18 13:38 ` Andreas Jaeger 2001-11-19 8:02 ` Richard Henderson @ 2001-11-27 7:24 ` Aldy Hernandez 2 siblings, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-27 7:24 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc > 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-18 5:09 ` Joseph S. Myers 2001-11-18 6:10 ` Aldy Hernandez 2001-11-18 12:41 ` Aldy Hernandez @ 2001-11-26 17:04 ` Joseph S. Myers 2 siblings, 0 replies; 229+ messages in thread From: Joseph S. Myers @ 2001-11-26 17:04 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Aldy Hernandez, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-18 4:24 ` Aldy Hernandez 2001-11-18 5:09 ` Joseph S. Myers @ 2001-11-26 16:39 ` Aldy Hernandez 1 sibling, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-26 16:39 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Aldy Hernandez, gcc > > __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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-18 3:56 ` Joseph S. Myers 2001-11-18 4:24 ` Aldy Hernandez @ 2001-11-18 6:40 ` Ziemowit Laski 2001-11-18 6:33 ` Aldy Hernandez ` (2 more replies) 2001-11-26 15:45 ` front end changes for altivec Joseph S. Myers 2 siblings, 3 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-18 6:40 UTC (permalink / raw) To: gcc; +Cc: Aldy Hernandez, Joseph S. Myers 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-18 6:40 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski @ 2001-11-18 6:33 ` Aldy Hernandez 2001-11-26 18:46 ` Aldy Hernandez 2001-11-18 8:19 ` Stan Shebs 2001-11-26 18:47 ` Ziemowit Laski 2 siblings, 1 reply; 229+ messages in thread From: Aldy Hernandez @ 2001-11-18 6:33 UTC (permalink / raw) To: Ziemowit Laski; +Cc: gcc, Joseph S. Myers > 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-18 6:33 ` Aldy Hernandez @ 2001-11-26 18:46 ` Aldy Hernandez 0 siblings, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-26 18:46 UTC (permalink / raw) To: Ziemowit Laski; +Cc: gcc, Joseph S. Myers > 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-18 6:40 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski 2001-11-18 6:33 ` Aldy Hernandez @ 2001-11-18 8:19 ` Stan Shebs 2001-11-18 9:13 ` Ira Ruben 2001-11-26 22:22 ` Target-specific Front-Ends? (Was: front end changes for altivec) Stan Shebs 2001-11-26 18:47 ` Ziemowit Laski 2 siblings, 2 replies; 229+ messages in thread From: Stan Shebs @ 2001-11-18 8:19 UTC (permalink / raw) To: Ziemowit Laski; +Cc: gcc, Aldy Hernandez, Joseph S. Myers 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-18 8:19 ` Stan Shebs @ 2001-11-18 9:13 ` Ira Ruben 2001-11-18 12:26 ` Aldy Hernandez ` (3 more replies) 2001-11-26 22:22 ` Target-specific Front-Ends? (Was: front end changes for altivec) Stan Shebs 1 sibling, 4 replies; 229+ messages in thread From: Ira Ruben @ 2001-11-18 9:13 UTC (permalink / raw) To: Stan Shebs; +Cc: Ziemowit Laski, gcc, Aldy Hernandez, Joseph S. Myers 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-18 9:13 ` Ira Ruben @ 2001-11-18 12:26 ` Aldy Hernandez 2001-11-19 4:45 ` Ira Ruben ` (2 more replies) 2001-11-18 18:51 ` Per Bothner ` (2 subsequent siblings) 3 siblings, 3 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-18 12:26 UTC (permalink / raw) To: Ira Ruben; +Cc: Stan Shebs, Ziemowit Laski, gcc, Joseph S. Myers 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-18 12:26 ` Aldy Hernandez @ 2001-11-19 4:45 ` Ira Ruben 2001-11-19 6:04 ` Geoff Keating ` (2 more replies) 2001-11-19 6:26 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski 2001-11-27 6:46 ` Aldy Hernandez 2 siblings, 3 replies; 229+ messages in thread From: Ira Ruben @ 2001-11-19 4:45 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Stan Shebs, Ziemowit Laski, gcc, Joseph S. Myers 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 4:45 ` Ira Ruben @ 2001-11-19 6:04 ` Geoff Keating 2001-11-19 7:28 ` Ira Ruben 2001-11-27 12:10 ` Geoff Keating 2001-11-19 7:50 ` Aldy Hernandez 2001-11-27 10:53 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Ira Ruben 2 siblings, 2 replies; 229+ messages in thread From: Geoff Keating @ 2001-11-19 6:04 UTC (permalink / raw) To: Ira Ruben; +Cc: gcc 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> ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 6:04 ` Geoff Keating @ 2001-11-19 7:28 ` Ira Ruben 2001-11-19 12:04 ` Phil Edwards 2001-11-27 12:47 ` Ira Ruben 2001-11-27 12:10 ` Geoff Keating 1 sibling, 2 replies; 229+ messages in thread From: Ira Ruben @ 2001-11-19 7:28 UTC (permalink / raw) To: Geoff Keating; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 7:28 ` Ira Ruben @ 2001-11-19 12:04 ` Phil Edwards 2001-11-27 14:58 ` Phil Edwards 2001-11-27 12:47 ` Ira Ruben 1 sibling, 1 reply; 229+ messages in thread From: Phil Edwards @ 2001-11-19 12:04 UTC (permalink / raw) To: Ira Ruben; +Cc: Geoff Keating, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 12:04 ` Phil Edwards @ 2001-11-27 14:58 ` Phil Edwards 0 siblings, 0 replies; 229+ messages in thread From: Phil Edwards @ 2001-11-27 14:58 UTC (permalink / raw) To: Ira Ruben; +Cc: Geoff Keating, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 7:28 ` Ira Ruben 2001-11-19 12:04 ` Phil Edwards @ 2001-11-27 12:47 ` Ira Ruben 1 sibling, 0 replies; 229+ messages in thread From: Ira Ruben @ 2001-11-27 12:47 UTC (permalink / raw) To: Geoff Keating; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 6:04 ` Geoff Keating 2001-11-19 7:28 ` Ira Ruben @ 2001-11-27 12:10 ` Geoff Keating 1 sibling, 0 replies; 229+ messages in thread From: Geoff Keating @ 2001-11-27 12:10 UTC (permalink / raw) To: Ira Ruben; +Cc: gcc 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> ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 4:45 ` Ira Ruben 2001-11-19 6:04 ` Geoff Keating @ 2001-11-19 7:50 ` Aldy Hernandez 2001-11-27 13:12 ` Aldy Hernandez 2001-11-27 10:53 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Ira Ruben 2 siblings, 1 reply; 229+ messages in thread From: Aldy Hernandez @ 2001-11-19 7:50 UTC (permalink / raw) To: Ira Ruben; +Cc: Stan Shebs, Ziemowit Laski, gcc, Joseph S. Myers 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 7:50 ` Aldy Hernandez @ 2001-11-27 13:12 ` Aldy Hernandez 0 siblings, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-27 13:12 UTC (permalink / raw) To: Ira Ruben; +Cc: Stan Shebs, Ziemowit Laski, gcc, Joseph S. Myers 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes foraltivec) 2001-11-19 4:45 ` Ira Ruben 2001-11-19 6:04 ` Geoff Keating 2001-11-19 7:50 ` Aldy Hernandez @ 2001-11-27 10:53 ` Ira Ruben 2 siblings, 0 replies; 229+ messages in thread From: Ira Ruben @ 2001-11-27 10:53 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Stan Shebs, Ziemowit Laski, gcc, Joseph S. Myers 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-18 12:26 ` Aldy Hernandez 2001-11-19 4:45 ` Ira Ruben @ 2001-11-19 6:26 ` Ziemowit Laski 2001-11-19 7:53 ` Aldy Hernandez 2001-11-27 12:41 ` Ziemowit Laski 2001-11-27 6:46 ` Aldy Hernandez 2 siblings, 2 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-19 6:26 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Ira Ruben, Stan Shebs, gcc, Joseph S. Myers 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 6:26 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski @ 2001-11-19 7:53 ` Aldy Hernandez 2001-11-19 7:56 ` Ziemowit Laski 2001-11-27 13:13 ` Aldy Hernandez 2001-11-27 12:41 ` Ziemowit Laski 1 sibling, 2 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-19 7:53 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Ira Ruben, Stan Shebs, gcc, Joseph S. Myers 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 7:53 ` Aldy Hernandez @ 2001-11-19 7:56 ` Ziemowit Laski 2001-11-27 13:21 ` Ziemowit Laski 2001-11-27 13:13 ` Aldy Hernandez 1 sibling, 1 reply; 229+ messages in thread From: Ziemowit Laski @ 2001-11-19 7:56 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Ira Ruben, Stan Shebs, gcc, Joseph S. Myers 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 7:56 ` Ziemowit Laski @ 2001-11-27 13:21 ` Ziemowit Laski 0 siblings, 0 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-27 13:21 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Ira Ruben, Stan Shebs, gcc, Joseph S. Myers 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 7:53 ` Aldy Hernandez 2001-11-19 7:56 ` Ziemowit Laski @ 2001-11-27 13:13 ` Aldy Hernandez 1 sibling, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-27 13:13 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Ira Ruben, Stan Shebs, gcc, Joseph S. Myers 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 6:26 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski 2001-11-19 7:53 ` Aldy Hernandez @ 2001-11-27 12:41 ` Ziemowit Laski 1 sibling, 0 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-27 12:41 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Ira Ruben, Stan Shebs, gcc, Joseph S. Myers 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-18 12:26 ` Aldy Hernandez 2001-11-19 4:45 ` Ira Ruben 2001-11-19 6:26 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski @ 2001-11-27 6:46 ` Aldy Hernandez 2 siblings, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-27 6:46 UTC (permalink / raw) To: Ira Ruben; +Cc: Stan Shebs, Ziemowit Laski, gcc, Joseph S. Myers 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-18 9:13 ` Ira Ruben 2001-11-18 12:26 ` Aldy Hernandez @ 2001-11-18 18:51 ` Per Bothner 2001-11-27 9:20 ` Per Bothner 2001-11-18 23:55 ` Stan Shebs 2001-11-26 23:45 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Ira Ruben 3 siblings, 1 reply; 229+ messages in thread From: Per Bothner @ 2001-11-18 18:51 UTC (permalink / raw) To: Ira Ruben; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-18 18:51 ` Per Bothner @ 2001-11-27 9:20 ` Per Bothner 0 siblings, 0 replies; 229+ messages in thread From: Per Bothner @ 2001-11-27 9:20 UTC (permalink / raw) To: Ira Ruben; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-18 9:13 ` Ira Ruben 2001-11-18 12:26 ` Aldy Hernandez 2001-11-18 18:51 ` Per Bothner @ 2001-11-18 23:55 ` Stan Shebs 2001-11-19 4:18 ` Ira Ruben ` (2 more replies) 2001-11-26 23:45 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Ira Ruben 3 siblings, 3 replies; 229+ messages in thread From: Stan Shebs @ 2001-11-18 23:55 UTC (permalink / raw) To: Ira Ruben; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-18 23:55 ` Stan Shebs @ 2001-11-19 4:18 ` Ira Ruben 2001-11-19 4:48 ` Per Bothner 2001-11-27 10:47 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Ira Ruben 2001-11-19 6:19 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski 2001-11-27 9:48 ` Stan Shebs 2 siblings, 2 replies; 229+ messages in thread From: Ira Ruben @ 2001-11-19 4:18 UTC (permalink / raw) To: Stan Shebs; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 4:18 ` Ira Ruben @ 2001-11-19 4:48 ` Per Bothner 2001-11-19 5:28 ` Daniel Berlin ` (2 more replies) 2001-11-27 10:47 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Ira Ruben 1 sibling, 3 replies; 229+ messages in thread From: Per Bothner @ 2001-11-19 4:48 UTC (permalink / raw) To: Ira Ruben; +Cc: Stan Shebs, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 4:48 ` Per Bothner @ 2001-11-19 5:28 ` Daniel Berlin 2001-11-27 11:35 ` Daniel Berlin 2001-11-19 6:26 ` Ziemowit Laski 2001-11-27 11:16 ` Per Bothner 2 siblings, 1 reply; 229+ messages in thread From: Daniel Berlin @ 2001-11-19 5:28 UTC (permalink / raw) To: Per Bothner; +Cc: Ira Ruben, Stan Shebs, gcc 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 > > ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 5:28 ` Daniel Berlin @ 2001-11-27 11:35 ` Daniel Berlin 0 siblings, 0 replies; 229+ messages in thread From: Daniel Berlin @ 2001-11-27 11:35 UTC (permalink / raw) To: Per Bothner; +Cc: Ira Ruben, Stan Shebs, gcc 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 > > ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 4:48 ` Per Bothner 2001-11-19 5:28 ` Daniel Berlin @ 2001-11-19 6:26 ` Ziemowit Laski 2001-11-20 0:33 ` Per Bothner 2001-11-27 12:34 ` Ziemowit Laski 2001-11-27 11:16 ` Per Bothner 2 siblings, 2 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-19 6:26 UTC (permalink / raw) To: Per Bothner; +Cc: Ira Ruben, Stan Shebs, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 6:26 ` Ziemowit Laski @ 2001-11-20 0:33 ` Per Bothner 2001-11-20 3:16 ` Ziemowit Laski ` (2 more replies) 2001-11-27 12:34 ` Ziemowit Laski 1 sibling, 3 replies; 229+ messages in thread From: Per Bothner @ 2001-11-20 0:33 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Ira Ruben, Stan Shebs, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 0:33 ` Per Bothner @ 2001-11-20 3:16 ` Ziemowit Laski 2001-11-20 6:33 ` Per Bothner ` (2 more replies) 2001-11-20 3:19 ` Stan Shebs 2001-11-27 17:35 ` Per Bothner 2 siblings, 3 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-20 3:16 UTC (permalink / raw) To: Per Bothner; +Cc: Ira Ruben, Stan Shebs, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 3:16 ` Ziemowit Laski @ 2001-11-20 6:33 ` Per Bothner 2001-11-27 18:27 ` Per Bothner 2001-11-20 11:05 ` Stan Shebs 2001-11-27 18:06 ` Ziemowit Laski 2 siblings, 1 reply; 229+ messages in thread From: Per Bothner @ 2001-11-20 6:33 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Ira Ruben, Stan Shebs, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 6:33 ` Per Bothner @ 2001-11-27 18:27 ` Per Bothner 0 siblings, 0 replies; 229+ messages in thread From: Per Bothner @ 2001-11-27 18:27 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Ira Ruben, Stan Shebs, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 3:16 ` Ziemowit Laski 2001-11-20 6:33 ` Per Bothner @ 2001-11-20 11:05 ` Stan Shebs 2001-11-27 18:35 ` Stan Shebs 2001-11-27 18:06 ` Ziemowit Laski 2 siblings, 1 reply; 229+ messages in thread From: Stan Shebs @ 2001-11-20 11:05 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Per Bothner, Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 11:05 ` Stan Shebs @ 2001-11-27 18:35 ` Stan Shebs 0 siblings, 0 replies; 229+ messages in thread From: Stan Shebs @ 2001-11-27 18:35 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Per Bothner, Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 3:16 ` Ziemowit Laski 2001-11-20 6:33 ` Per Bothner 2001-11-20 11:05 ` Stan Shebs @ 2001-11-27 18:06 ` Ziemowit Laski 2 siblings, 0 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-27 18:06 UTC (permalink / raw) To: Per Bothner; +Cc: Ira Ruben, Stan Shebs, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 0:33 ` Per Bothner 2001-11-20 3:16 ` Ziemowit Laski @ 2001-11-20 3:19 ` Stan Shebs 2001-11-20 5:25 ` Joseph S. Myers ` (3 more replies) 2001-11-27 17:35 ` Per Bothner 2 siblings, 4 replies; 229+ messages in thread From: Stan Shebs @ 2001-11-20 3:19 UTC (permalink / raw) To: Per Bothner; +Cc: Ziemowit Laski, Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 3:19 ` Stan Shebs @ 2001-11-20 5:25 ` Joseph S. Myers 2001-11-27 18:24 ` Joseph S. Myers 2001-11-20 11:27 ` Per Bothner ` (2 subsequent siblings) 3 siblings, 1 reply; 229+ messages in thread From: Joseph S. Myers @ 2001-11-20 5:25 UTC (permalink / raw) To: Stan Shebs; +Cc: Per Bothner, Ziemowit Laski, Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 5:25 ` Joseph S. Myers @ 2001-11-27 18:24 ` Joseph S. Myers 0 siblings, 0 replies; 229+ messages in thread From: Joseph S. Myers @ 2001-11-27 18:24 UTC (permalink / raw) To: Stan Shebs; +Cc: Per Bothner, Ziemowit Laski, Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 3:19 ` Stan Shebs 2001-11-20 5:25 ` Joseph S. Myers @ 2001-11-20 11:27 ` Per Bothner 2001-11-27 19:59 ` Per Bothner 2001-11-20 11:37 ` Mark Mitchell 2001-11-27 18:09 ` Target-specific Front-Ends? (Was: front end changes for altivec) Stan Shebs 3 siblings, 1 reply; 229+ messages in thread From: Per Bothner @ 2001-11-20 11:27 UTC (permalink / raw) To: Stan Shebs; +Cc: Ziemowit Laski, Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 11:27 ` Per Bothner @ 2001-11-27 19:59 ` Per Bothner 0 siblings, 0 replies; 229+ messages in thread From: Per Bothner @ 2001-11-27 19:59 UTC (permalink / raw) To: Stan Shebs; +Cc: Ziemowit Laski, Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 3:19 ` Stan Shebs 2001-11-20 5:25 ` Joseph S. Myers 2001-11-20 11:27 ` Per Bothner @ 2001-11-20 11:37 ` Mark Mitchell 2001-11-20 17:03 ` Aldy Hernandez ` (2 more replies) 2001-11-27 18:09 ` Target-specific Front-Ends? (Was: front end changes for altivec) Stan Shebs 3 siblings, 3 replies; 229+ messages in thread From: Mark Mitchell @ 2001-11-20 11:37 UTC (permalink / raw) To: Stan Shebs, Per Bothner; +Cc: Ziemowit Laski, Ira Ruben, gcc >> 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 11:37 ` Mark Mitchell @ 2001-11-20 17:03 ` Aldy Hernandez 2001-11-20 18:25 ` Mark Mitchell 2001-11-28 7:11 ` Target-specific Front-Ends? (Was: front end changes for altivec) Aldy Hernandez 2001-11-20 19:20 ` Stan Shebs 2001-11-27 20:40 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Mark Mitchell 2 siblings, 2 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-20 17:03 UTC (permalink / raw) To: Mark Mitchell; +Cc: Stan Shebs, Per Bothner, Ziemowit Laski, Ira Ruben, gcc >>>>> "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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 17:03 ` Aldy Hernandez @ 2001-11-20 18:25 ` Mark Mitchell 2001-11-28 9:45 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Mark Mitchell 2001-11-28 7:11 ` Target-specific Front-Ends? (Was: front end changes for altivec) Aldy Hernandez 1 sibling, 1 reply; 229+ messages in thread From: Mark Mitchell @ 2001-11-20 18:25 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Stan Shebs, Per Bothner, Ziemowit Laski, Ira Ruben, gcc > > > 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes foraltivec) 2001-11-20 18:25 ` Mark Mitchell @ 2001-11-28 9:45 ` Mark Mitchell 0 siblings, 0 replies; 229+ messages in thread From: Mark Mitchell @ 2001-11-28 9:45 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Stan Shebs, Per Bothner, Ziemowit Laski, Ira Ruben, gcc > > > 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 17:03 ` Aldy Hernandez 2001-11-20 18:25 ` Mark Mitchell @ 2001-11-28 7:11 ` Aldy Hernandez 1 sibling, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-28 7:11 UTC (permalink / raw) To: Mark Mitchell; +Cc: Stan Shebs, Per Bothner, Ziemowit Laski, Ira Ruben, gcc >>>>> "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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 11:37 ` Mark Mitchell 2001-11-20 17:03 ` Aldy Hernandez @ 2001-11-20 19:20 ` Stan Shebs 2001-11-20 20:24 ` Mark Mitchell ` (2 more replies) 2001-11-27 20:40 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Mark Mitchell 2 siblings, 3 replies; 229+ messages in thread From: Stan Shebs @ 2001-11-20 19:20 UTC (permalink / raw) To: Mark Mitchell; +Cc: Per Bothner, Ziemowit Laski, Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 19:20 ` Stan Shebs @ 2001-11-20 20:24 ` Mark Mitchell 2001-11-20 23:47 ` Target-specific Front-Ends? (Was: front end changes for Joe Buck 2001-11-28 11:31 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Mark Mitchell 2001-11-20 20:27 ` Target-specific Front-Ends? (Was: front end changes for altivec) Dale Johannesen 2001-11-28 11:19 ` Stan Shebs 2 siblings, 2 replies; 229+ messages in thread From: Mark Mitchell @ 2001-11-20 20:24 UTC (permalink / raw) To: Stan Shebs; +Cc: Per Bothner, Ziemowit Laski, Ira Ruben, gcc > 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 20:24 ` Mark Mitchell @ 2001-11-20 23:47 ` Joe Buck 2001-11-28 12:43 ` Joe Buck 2001-11-28 11:31 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Mark Mitchell 1 sibling, 1 reply; 229+ messages in thread From: Joe Buck @ 2001-11-20 23:47 UTC (permalink / raw) To: Mark Mitchell; +Cc: Stan Shebs, Per Bothner, Ziemowit Laski, Ira Ruben, gcc > > 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? ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 23:47 ` Target-specific Front-Ends? (Was: front end changes for Joe Buck @ 2001-11-28 12:43 ` Joe Buck 0 siblings, 0 replies; 229+ messages in thread From: Joe Buck @ 2001-11-28 12:43 UTC (permalink / raw) To: Mark Mitchell; +Cc: Stan Shebs, Per Bothner, Ziemowit Laski, Ira Ruben, gcc > > 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? ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes foraltivec) 2001-11-20 20:24 ` Mark Mitchell 2001-11-20 23:47 ` Target-specific Front-Ends? (Was: front end changes for Joe Buck @ 2001-11-28 11:31 ` Mark Mitchell 1 sibling, 0 replies; 229+ messages in thread From: Mark Mitchell @ 2001-11-28 11:31 UTC (permalink / raw) To: Stan Shebs; +Cc: Per Bothner, Ziemowit Laski, Ira Ruben, gcc > 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 19:20 ` Stan Shebs 2001-11-20 20:24 ` Mark Mitchell @ 2001-11-20 20:27 ` Dale Johannesen 2001-11-20 20:38 ` Stan Shebs 2001-11-28 11:44 ` Dale Johannesen 2001-11-28 11:19 ` Stan Shebs 2 siblings, 2 replies; 229+ messages in thread From: Dale Johannesen @ 2001-11-20 20:27 UTC (permalink / raw) To: Stan Shebs Cc: Dale Johannesen, Mark Mitchell, Per Bothner, Ziemowit Laski, Ira Ruben, gcc, compiler_group > 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 20:27 ` Target-specific Front-Ends? (Was: front end changes for altivec) Dale Johannesen @ 2001-11-20 20:38 ` Stan Shebs 2001-11-21 4:47 ` Syd Polk 2001-11-28 11:55 ` Stan Shebs 2001-11-28 11:44 ` Dale Johannesen 1 sibling, 2 replies; 229+ messages in thread From: Stan Shebs @ 2001-11-20 20:38 UTC (permalink / raw) To: Dale Johannesen Cc: Mark Mitchell, Per Bothner, Ziemowit Laski, Ira Ruben, gcc, compiler_group 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 20:38 ` Stan Shebs @ 2001-11-21 4:47 ` Syd Polk 2001-11-21 12:31 ` Tim Hollebeek 2001-11-28 14:12 ` Syd Polk 2001-11-28 11:55 ` Stan Shebs 1 sibling, 2 replies; 229+ messages in thread From: Syd Polk @ 2001-11-21 4:47 UTC (permalink / raw) To: Stan Shebs Cc: Dale Johannesen, Mark Mitchell, Per Bothner, Ziemowit Laski, Ira Ruben, gcc, compiler_group 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-21 4:47 ` Syd Polk @ 2001-11-21 12:31 ` Tim Hollebeek 2001-11-28 16:15 ` Tim Hollebeek 2001-11-28 14:12 ` Syd Polk 1 sibling, 1 reply; 229+ messages in thread From: Tim Hollebeek @ 2001-11-21 12:31 UTC (permalink / raw) To: Syd Polk Cc: Stan Shebs, Dale Johannesen, Mark Mitchell, Per Bothner, Ziemowit Laski, Ira Ruben, gcc, compiler_group > 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-21 12:31 ` Tim Hollebeek @ 2001-11-28 16:15 ` Tim Hollebeek 0 siblings, 0 replies; 229+ messages in thread From: Tim Hollebeek @ 2001-11-28 16:15 UTC (permalink / raw) To: Syd Polk Cc: Stan Shebs, Dale Johannesen, Mark Mitchell, Per Bothner, Ziemowit Laski, Ira Ruben, gcc, compiler_group > 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-21 4:47 ` Syd Polk 2001-11-21 12:31 ` Tim Hollebeek @ 2001-11-28 14:12 ` Syd Polk 1 sibling, 0 replies; 229+ messages in thread From: Syd Polk @ 2001-11-28 14:12 UTC (permalink / raw) To: Stan Shebs Cc: Dale Johannesen, Mark Mitchell, Per Bothner, Ziemowit Laski, Ira Ruben, gcc, compiler_group 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 20:38 ` Stan Shebs 2001-11-21 4:47 ` Syd Polk @ 2001-11-28 11:55 ` Stan Shebs 1 sibling, 0 replies; 229+ messages in thread From: Stan Shebs @ 2001-11-28 11:55 UTC (permalink / raw) To: Dale Johannesen Cc: Mark Mitchell, Per Bothner, Ziemowit Laski, Ira Ruben, gcc, compiler_group 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 20:27 ` Target-specific Front-Ends? (Was: front end changes for altivec) Dale Johannesen 2001-11-20 20:38 ` Stan Shebs @ 2001-11-28 11:44 ` Dale Johannesen 1 sibling, 0 replies; 229+ messages in thread From: Dale Johannesen @ 2001-11-28 11:44 UTC (permalink / raw) To: Stan Shebs Cc: Dale Johannesen, Mark Mitchell, Per Bothner, Ziemowit Laski, Ira Ruben, gcc, compiler_group > 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 19:20 ` Stan Shebs 2001-11-20 20:24 ` Mark Mitchell 2001-11-20 20:27 ` Target-specific Front-Ends? (Was: front end changes for altivec) Dale Johannesen @ 2001-11-28 11:19 ` Stan Shebs 2 siblings, 0 replies; 229+ messages in thread From: Stan Shebs @ 2001-11-28 11:19 UTC (permalink / raw) To: Mark Mitchell; +Cc: Per Bothner, Ziemowit Laski, Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes foraltivec) 2001-11-20 11:37 ` Mark Mitchell 2001-11-20 17:03 ` Aldy Hernandez 2001-11-20 19:20 ` Stan Shebs @ 2001-11-27 20:40 ` Mark Mitchell 2 siblings, 0 replies; 229+ messages in thread From: Mark Mitchell @ 2001-11-27 20:40 UTC (permalink / raw) To: Stan Shebs, Per Bothner; +Cc: Ziemowit Laski, Ira Ruben, gcc >> 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 3:19 ` Stan Shebs ` (2 preceding siblings ...) 2001-11-20 11:37 ` Mark Mitchell @ 2001-11-27 18:09 ` Stan Shebs 3 siblings, 0 replies; 229+ messages in thread From: Stan Shebs @ 2001-11-27 18:09 UTC (permalink / raw) To: Per Bothner; +Cc: Ziemowit Laski, Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-20 0:33 ` Per Bothner 2001-11-20 3:16 ` Ziemowit Laski 2001-11-20 3:19 ` Stan Shebs @ 2001-11-27 17:35 ` Per Bothner 2 siblings, 0 replies; 229+ messages in thread From: Per Bothner @ 2001-11-27 17:35 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Ira Ruben, Stan Shebs, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 6:26 ` Ziemowit Laski 2001-11-20 0:33 ` Per Bothner @ 2001-11-27 12:34 ` Ziemowit Laski 1 sibling, 0 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-27 12:34 UTC (permalink / raw) To: Per Bothner; +Cc: Ira Ruben, Stan Shebs, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 4:48 ` Per Bothner 2001-11-19 5:28 ` Daniel Berlin 2001-11-19 6:26 ` Ziemowit Laski @ 2001-11-27 11:16 ` Per Bothner 2 siblings, 0 replies; 229+ messages in thread From: Per Bothner @ 2001-11-27 11:16 UTC (permalink / raw) To: Ira Ruben; +Cc: Stan Shebs, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes foraltivec) 2001-11-19 4:18 ` Ira Ruben 2001-11-19 4:48 ` Per Bothner @ 2001-11-27 10:47 ` Ira Ruben 1 sibling, 0 replies; 229+ messages in thread From: Ira Ruben @ 2001-11-27 10:47 UTC (permalink / raw) To: Stan Shebs; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-18 23:55 ` Stan Shebs 2001-11-19 4:18 ` Ira Ruben @ 2001-11-19 6:19 ` Ziemowit Laski 2001-11-19 7:13 ` Joseph S. Myers ` (4 more replies) 2001-11-27 9:48 ` Stan Shebs 2 siblings, 5 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-19 6:19 UTC (permalink / raw) To: Stan Shebs; +Cc: Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 6:19 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski @ 2001-11-19 7:13 ` Joseph S. Myers 2001-11-19 7:34 ` Stan Shebs ` (2 more replies) 2001-11-19 8:34 ` Aldy Hernandez ` (3 subsequent siblings) 4 siblings, 3 replies; 229+ messages in thread From: Joseph S. Myers @ 2001-11-19 7:13 UTC (permalink / raw) To: Ziemowit Laski; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 7:13 ` Joseph S. Myers @ 2001-11-19 7:34 ` Stan Shebs 2001-11-19 8:01 ` Joseph S. Myers 2001-11-27 12:57 ` Stan Shebs 2001-11-19 7:56 ` Ziemowit Laski 2001-11-27 12:44 ` Joseph S. Myers 2 siblings, 2 replies; 229+ messages in thread From: Stan Shebs @ 2001-11-19 7:34 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Ziemowit Laski, gcc "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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 7:34 ` Stan Shebs @ 2001-11-19 8:01 ` Joseph S. Myers 2001-11-19 9:18 ` Aldy Hernandez 2001-11-27 13:27 ` Joseph S. Myers 2001-11-27 12:57 ` Stan Shebs 1 sibling, 2 replies; 229+ messages in thread From: Joseph S. Myers @ 2001-11-19 8:01 UTC (permalink / raw) To: Stan Shebs; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 8:01 ` Joseph S. Myers @ 2001-11-19 9:18 ` Aldy Hernandez 2001-11-19 11:23 ` Dale Johannesen 2001-11-27 13:56 ` Aldy Hernandez 2001-11-27 13:27 ` Joseph S. Myers 1 sibling, 2 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-19 9:18 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Stan Shebs, gcc >>>>> "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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 9:18 ` Aldy Hernandez @ 2001-11-19 11:23 ` Dale Johannesen 2001-11-27 14:46 ` Dale Johannesen 2001-11-27 13:56 ` Aldy Hernandez 1 sibling, 1 reply; 229+ messages in thread From: Dale Johannesen @ 2001-11-19 11:23 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Dale Johannesen, Joseph S. Myers, Stan Shebs, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 11:23 ` Dale Johannesen @ 2001-11-27 14:46 ` Dale Johannesen 0 siblings, 0 replies; 229+ messages in thread From: Dale Johannesen @ 2001-11-27 14:46 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Dale Johannesen, Joseph S. Myers, Stan Shebs, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 9:18 ` Aldy Hernandez 2001-11-19 11:23 ` Dale Johannesen @ 2001-11-27 13:56 ` Aldy Hernandez 1 sibling, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-27 13:56 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Stan Shebs, gcc >>>>> "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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 8:01 ` Joseph S. Myers 2001-11-19 9:18 ` Aldy Hernandez @ 2001-11-27 13:27 ` Joseph S. Myers 1 sibling, 0 replies; 229+ messages in thread From: Joseph S. Myers @ 2001-11-27 13:27 UTC (permalink / raw) To: Stan Shebs; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 7:34 ` Stan Shebs 2001-11-19 8:01 ` Joseph S. Myers @ 2001-11-27 12:57 ` Stan Shebs 1 sibling, 0 replies; 229+ messages in thread From: Stan Shebs @ 2001-11-27 12:57 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Ziemowit Laski, gcc "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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 7:13 ` Joseph S. Myers 2001-11-19 7:34 ` Stan Shebs @ 2001-11-19 7:56 ` Ziemowit Laski 2001-11-19 8:31 ` Richard Henderson ` (2 more replies) 2001-11-27 12:44 ` Joseph S. Myers 2 siblings, 3 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-19 7:56 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 7:56 ` Ziemowit Laski @ 2001-11-19 8:31 ` Richard Henderson 2001-11-27 13:44 ` Richard Henderson 2001-11-19 10:23 ` Mark Mitchell 2001-11-27 13:19 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski 2 siblings, 1 reply; 229+ messages in thread From: Richard Henderson @ 2001-11-19 8:31 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Joseph S. Myers, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 8:31 ` Richard Henderson @ 2001-11-27 13:44 ` Richard Henderson 0 siblings, 0 replies; 229+ messages in thread From: Richard Henderson @ 2001-11-27 13:44 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Joseph S. Myers, gcc 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~ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 7:56 ` Ziemowit Laski 2001-11-19 8:31 ` Richard Henderson @ 2001-11-19 10:23 ` Mark Mitchell 2001-11-19 11:55 ` Target-specific Front-Ends? (Was: front end changes for Joe Buck 2001-11-27 14:36 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Mark Mitchell 2001-11-27 13:19 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski 2 siblings, 2 replies; 229+ messages in thread From: Mark Mitchell @ 2001-11-19 10:23 UTC (permalink / raw) To: Ziemowit Laski, Joseph S. Myers; +Cc: gcc > 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-19 10:23 ` Mark Mitchell @ 2001-11-19 11:55 ` Joe Buck 2001-11-19 14:03 ` Mark Mitchell 2001-11-27 14:53 ` Joe Buck 2001-11-27 14:36 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Mark Mitchell 1 sibling, 2 replies; 229+ messages in thread From: Joe Buck @ 2001-11-19 11:55 UTC (permalink / raw) To: Mark Mitchell; +Cc: Ziemowit Laski, Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-19 11:55 ` Target-specific Front-Ends? (Was: front end changes for Joe Buck @ 2001-11-19 14:03 ` Mark Mitchell 2001-11-19 14:46 ` Joe Buck ` (4 more replies) 2001-11-27 14:53 ` Joe Buck 1 sibling, 5 replies; 229+ messages in thread From: Mark Mitchell @ 2001-11-19 14:03 UTC (permalink / raw) To: Joe Buck; +Cc: Ziemowit Laski, Joseph S. Myers, gcc --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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-19 14:03 ` Mark Mitchell @ 2001-11-19 14:46 ` Joe Buck 2001-11-27 16:13 ` Joe Buck 2001-11-20 0:56 ` Devang Patel ` (3 subsequent siblings) 4 siblings, 1 reply; 229+ messages in thread From: Joe Buck @ 2001-11-19 14:46 UTC (permalink / raw) To: Mark Mitchell; +Cc: Joe Buck, Ziemowit Laski, Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-19 14:46 ` Joe Buck @ 2001-11-27 16:13 ` Joe Buck 0 siblings, 0 replies; 229+ messages in thread From: Joe Buck @ 2001-11-27 16:13 UTC (permalink / raw) To: Mark Mitchell; +Cc: Joe Buck, Ziemowit Laski, Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-19 14:03 ` Mark Mitchell 2001-11-19 14:46 ` Joe Buck @ 2001-11-20 0:56 ` Devang Patel 2001-11-27 17:37 ` Devang Patel 2001-11-20 5:17 ` Aldy Hernandez ` (2 subsequent siblings) 4 siblings, 1 reply; 229+ messages in thread From: Devang Patel @ 2001-11-20 0:56 UTC (permalink / raw) To: Mark Mitchell Cc: Devang Patel, Joe Buck, Ziemowit Laski, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 0:56 ` Devang Patel @ 2001-11-27 17:37 ` Devang Patel 0 siblings, 0 replies; 229+ messages in thread From: Devang Patel @ 2001-11-27 17:37 UTC (permalink / raw) To: Mark Mitchell Cc: Devang Patel, Joe Buck, Ziemowit Laski, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-19 14:03 ` Mark Mitchell 2001-11-19 14:46 ` Joe Buck 2001-11-20 0:56 ` Devang Patel @ 2001-11-20 5:17 ` Aldy Hernandez 2001-11-20 11:15 ` Ziemowit Laski ` (2 more replies) 2001-11-27 15:32 ` Mark Mitchell 2001-12-04 0:14 ` Alex Rosenberg 4 siblings, 3 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-20 5:17 UTC (permalink / raw) To: Mark Mitchell; +Cc: Joe Buck, Ziemowit Laski, Joseph S. Myers, gcc >>>>> "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? ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 5:17 ` Aldy Hernandez @ 2001-11-20 11:15 ` Ziemowit Laski 2001-11-20 17:09 ` Aldy Hernandez 2001-11-27 19:40 ` Ziemowit Laski 2001-11-20 19:17 ` Devang Patel 2001-11-27 18:21 ` Aldy Hernandez 2 siblings, 2 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-20 11:15 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Mark Mitchell, Joe Buck, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 11:15 ` Ziemowit Laski @ 2001-11-20 17:09 ` Aldy Hernandez 2001-11-20 17:26 ` Joe Buck ` (2 more replies) 2001-11-27 19:40 ` Ziemowit Laski 1 sibling, 3 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-20 17:09 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Mark Mitchell, Joe Buck, Joseph S. Myers, gcc >>>>> "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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 17:09 ` Aldy Hernandez @ 2001-11-20 17:26 ` Joe Buck 2001-11-20 17:57 ` Aldy Hernandez 2001-11-28 9:11 ` Joe Buck 2001-11-20 20:53 ` Ziemowit Laski 2001-11-28 7:33 ` Aldy Hernandez 2 siblings, 2 replies; 229+ messages in thread From: Joe Buck @ 2001-11-20 17:26 UTC (permalink / raw) To: Aldy Hernandez Cc: Ziemowit Laski, Mark Mitchell, Joe Buck, Joseph S. Myers, gcc 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). ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 17:26 ` Joe Buck @ 2001-11-20 17:57 ` Aldy Hernandez 2001-11-20 19:16 ` Neil Booth 2001-11-28 9:16 ` Aldy Hernandez 2001-11-28 9:11 ` Joe Buck 1 sibling, 2 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-20 17:57 UTC (permalink / raw) To: Joe Buck; +Cc: Ziemowit Laski, Mark Mitchell, Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 17:57 ` Aldy Hernandez @ 2001-11-20 19:16 ` Neil Booth 2001-11-20 21:10 ` Input Stream Rewriting (Was: Target-specific Front-Ends?) Ziemowit Laski 2001-11-28 11:06 ` Target-specific Front-Ends? (Was: front end changes for Neil Booth 2001-11-28 9:16 ` Aldy Hernandez 1 sibling, 2 replies; 229+ messages in thread From: Neil Booth @ 2001-11-20 19:16 UTC (permalink / raw) To: Aldy Hernandez Cc: Joe Buck, Ziemowit Laski, Mark Mitchell, Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Input Stream Rewriting (Was: Target-specific Front-Ends?) 2001-11-20 19:16 ` Neil Booth @ 2001-11-20 21:10 ` Ziemowit Laski 2001-11-21 0:24 ` Neil Booth 2001-11-28 12:01 ` Ziemowit Laski 2001-11-28 11:06 ` Target-specific Front-Ends? (Was: front end changes for Neil Booth 1 sibling, 2 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-20 21:10 UTC (permalink / raw) To: Neil Booth; +Cc: Aldy Hernandez, Joe Buck, Mark Mitchell, Joseph S. Myers, gcc (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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Input Stream Rewriting (Was: Target-specific Front-Ends?) 2001-11-20 21:10 ` Input Stream Rewriting (Was: Target-specific Front-Ends?) Ziemowit Laski @ 2001-11-21 0:24 ` Neil Booth 2001-11-21 1:05 ` Ziemowit Laski 2001-11-28 12:45 ` Neil Booth 2001-11-28 12:01 ` Ziemowit Laski 1 sibling, 2 replies; 229+ messages in thread From: Neil Booth @ 2001-11-21 0:24 UTC (permalink / raw) To: Ziemowit Laski Cc: Aldy Hernandez, Joe Buck, Mark Mitchell, Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Input Stream Rewriting (Was: Target-specific Front-Ends?) 2001-11-21 0:24 ` Neil Booth @ 2001-11-21 1:05 ` Ziemowit Laski 2001-11-21 4:38 ` Neil Booth 2001-11-28 13:25 ` Ziemowit Laski 2001-11-28 12:45 ` Neil Booth 1 sibling, 2 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-21 1:05 UTC (permalink / raw) To: Neil Booth; +Cc: Aldy Hernandez, Joe Buck, Mark Mitchell, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Input Stream Rewriting (Was: Target-specific Front-Ends?) 2001-11-21 1:05 ` Ziemowit Laski @ 2001-11-21 4:38 ` Neil Booth 2001-11-28 13:57 ` Neil Booth 2001-11-28 13:25 ` Ziemowit Laski 1 sibling, 1 reply; 229+ messages in thread From: Neil Booth @ 2001-11-21 4:38 UTC (permalink / raw) To: Ziemowit Laski Cc: Aldy Hernandez, Joe Buck, Mark Mitchell, Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Input Stream Rewriting (Was: Target-specific Front-Ends?) 2001-11-21 4:38 ` Neil Booth @ 2001-11-28 13:57 ` Neil Booth 0 siblings, 0 replies; 229+ messages in thread From: Neil Booth @ 2001-11-28 13:57 UTC (permalink / raw) To: Ziemowit Laski Cc: Aldy Hernandez, Joe Buck, Mark Mitchell, Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Input Stream Rewriting (Was: Target-specific Front-Ends?) 2001-11-21 1:05 ` Ziemowit Laski 2001-11-21 4:38 ` Neil Booth @ 2001-11-28 13:25 ` Ziemowit Laski 1 sibling, 0 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-28 13:25 UTC (permalink / raw) To: Neil Booth; +Cc: Aldy Hernandez, Joe Buck, Mark Mitchell, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Input Stream Rewriting (Was: Target-specific Front-Ends?) 2001-11-21 0:24 ` Neil Booth 2001-11-21 1:05 ` Ziemowit Laski @ 2001-11-28 12:45 ` Neil Booth 1 sibling, 0 replies; 229+ messages in thread From: Neil Booth @ 2001-11-28 12:45 UTC (permalink / raw) To: Ziemowit Laski Cc: Aldy Hernandez, Joe Buck, Mark Mitchell, Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Input Stream Rewriting (Was: Target-specific Front-Ends?) 2001-11-20 21:10 ` Input Stream Rewriting (Was: Target-specific Front-Ends?) Ziemowit Laski 2001-11-21 0:24 ` Neil Booth @ 2001-11-28 12:01 ` Ziemowit Laski 1 sibling, 0 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-28 12:01 UTC (permalink / raw) To: Neil Booth; +Cc: Aldy Hernandez, Joe Buck, Mark Mitchell, Joseph S. Myers, gcc (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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 19:16 ` Neil Booth 2001-11-20 21:10 ` Input Stream Rewriting (Was: Target-specific Front-Ends?) Ziemowit Laski @ 2001-11-28 11:06 ` Neil Booth 1 sibling, 0 replies; 229+ messages in thread From: Neil Booth @ 2001-11-28 11:06 UTC (permalink / raw) To: Aldy Hernandez Cc: Joe Buck, Ziemowit Laski, Mark Mitchell, Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 17:57 ` Aldy Hernandez 2001-11-20 19:16 ` Neil Booth @ 2001-11-28 9:16 ` Aldy Hernandez 1 sibling, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-28 9:16 UTC (permalink / raw) To: Joe Buck; +Cc: Ziemowit Laski, Mark Mitchell, Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 17:26 ` Joe Buck 2001-11-20 17:57 ` Aldy Hernandez @ 2001-11-28 9:11 ` Joe Buck 1 sibling, 0 replies; 229+ messages in thread From: Joe Buck @ 2001-11-28 9:11 UTC (permalink / raw) To: Aldy Hernandez Cc: Ziemowit Laski, Mark Mitchell, Joe Buck, Joseph S. Myers, gcc 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). ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 17:09 ` Aldy Hernandez 2001-11-20 17:26 ` Joe Buck @ 2001-11-20 20:53 ` Ziemowit Laski 2001-11-20 22:08 ` Joe Buck ` (2 more replies) 2001-11-28 7:33 ` Aldy Hernandez 2 siblings, 3 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-20 20:53 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Mark Mitchell, Joe Buck, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 20:53 ` Ziemowit Laski @ 2001-11-20 22:08 ` Joe Buck 2001-11-28 12:26 ` Joe Buck 2001-11-20 23:37 ` Per Bothner 2001-11-28 11:55 ` Ziemowit Laski 2 siblings, 1 reply; 229+ messages in thread From: Joe Buck @ 2001-11-20 22:08 UTC (permalink / raw) To: Ziemowit Laski Cc: Mark Mitchell, Joe Buck, Joseph S. Myers, gcc, Aldy Hernandez 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 22:08 ` Joe Buck @ 2001-11-28 12:26 ` Joe Buck 0 siblings, 0 replies; 229+ messages in thread From: Joe Buck @ 2001-11-28 12:26 UTC (permalink / raw) To: Ziemowit Laski Cc: Mark Mitchell, Joe Buck, Joseph S. Myers, gcc, Aldy Hernandez 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 20:53 ` Ziemowit Laski 2001-11-20 22:08 ` Joe Buck @ 2001-11-20 23:37 ` Per Bothner 2001-11-21 3:14 ` Ziemowit Laski 2001-11-28 12:36 ` Per Bothner 2001-11-28 11:55 ` Ziemowit Laski 2 siblings, 2 replies; 229+ messages in thread From: Per Bothner @ 2001-11-20 23:37 UTC (permalink / raw) To: Ziemowit Laski; +Cc: gcc 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/ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 23:37 ` Per Bothner @ 2001-11-21 3:14 ` Ziemowit Laski 2001-11-21 12:32 ` David Edelsohn 2001-11-28 13:36 ` Ziemowit Laski 2001-11-28 12:36 ` Per Bothner 1 sibling, 2 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-21 3:14 UTC (permalink / raw) To: Per Bothner; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-21 3:14 ` Ziemowit Laski @ 2001-11-21 12:32 ` David Edelsohn 2001-11-21 12:44 ` Ziemowit Laski 2001-11-28 18:29 ` David Edelsohn 2001-11-28 13:36 ` Ziemowit Laski 1 sibling, 2 replies; 229+ messages in thread From: David Edelsohn @ 2001-11-21 12:32 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Per Bothner, gcc >>>>> 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-21 12:32 ` David Edelsohn @ 2001-11-21 12:44 ` Ziemowit Laski 2001-11-28 18:40 ` Ziemowit Laski 2001-11-28 18:29 ` David Edelsohn 1 sibling, 1 reply; 229+ messages in thread From: Ziemowit Laski @ 2001-11-21 12:44 UTC (permalink / raw) To: David Edelsohn; +Cc: Per Bothner, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-21 12:44 ` Ziemowit Laski @ 2001-11-28 18:40 ` Ziemowit Laski 0 siblings, 0 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-28 18:40 UTC (permalink / raw) To: David Edelsohn; +Cc: Per Bothner, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-21 12:32 ` David Edelsohn 2001-11-21 12:44 ` Ziemowit Laski @ 2001-11-28 18:29 ` David Edelsohn 1 sibling, 0 replies; 229+ messages in thread From: David Edelsohn @ 2001-11-28 18:29 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Per Bothner, gcc >>>>> 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-21 3:14 ` Ziemowit Laski 2001-11-21 12:32 ` David Edelsohn @ 2001-11-28 13:36 ` Ziemowit Laski 1 sibling, 0 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-28 13:36 UTC (permalink / raw) To: Per Bothner; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 23:37 ` Per Bothner 2001-11-21 3:14 ` Ziemowit Laski @ 2001-11-28 12:36 ` Per Bothner 1 sibling, 0 replies; 229+ messages in thread From: Per Bothner @ 2001-11-28 12:36 UTC (permalink / raw) To: Ziemowit Laski; +Cc: gcc 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/ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 20:53 ` Ziemowit Laski 2001-11-20 22:08 ` Joe Buck 2001-11-20 23:37 ` Per Bothner @ 2001-11-28 11:55 ` Ziemowit Laski 2 siblings, 0 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-28 11:55 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Mark Mitchell, Joe Buck, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 17:09 ` Aldy Hernandez 2001-11-20 17:26 ` Joe Buck 2001-11-20 20:53 ` Ziemowit Laski @ 2001-11-28 7:33 ` Aldy Hernandez 2 siblings, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-28 7:33 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Mark Mitchell, Joe Buck, Joseph S. Myers, gcc >>>>> "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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 11:15 ` Ziemowit Laski 2001-11-20 17:09 ` Aldy Hernandez @ 2001-11-27 19:40 ` Ziemowit Laski 1 sibling, 0 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-27 19:40 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Mark Mitchell, Joe Buck, Joseph S. Myers, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 5:17 ` Aldy Hernandez 2001-11-20 11:15 ` Ziemowit Laski @ 2001-11-20 19:17 ` Devang Patel 2001-11-28 11:09 ` Devang Patel 2001-11-27 18:21 ` Aldy Hernandez 2 siblings, 1 reply; 229+ messages in thread From: Devang Patel @ 2001-11-20 19:17 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Devang Patel, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 19:17 ` Devang Patel @ 2001-11-28 11:09 ` Devang Patel 0 siblings, 0 replies; 229+ messages in thread From: Devang Patel @ 2001-11-28 11:09 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Devang Patel, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-20 5:17 ` Aldy Hernandez 2001-11-20 11:15 ` Ziemowit Laski 2001-11-20 19:17 ` Devang Patel @ 2001-11-27 18:21 ` Aldy Hernandez 2 siblings, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-27 18:21 UTC (permalink / raw) To: Mark Mitchell; +Cc: Joe Buck, Ziemowit Laski, Joseph S. Myers, gcc >>>>> "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? ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-19 14:03 ` Mark Mitchell ` (2 preceding siblings ...) 2001-11-20 5:17 ` Aldy Hernandez @ 2001-11-27 15:32 ` Mark Mitchell 2001-12-04 0:14 ` Alex Rosenberg 4 siblings, 0 replies; 229+ messages in thread From: Mark Mitchell @ 2001-11-27 15:32 UTC (permalink / raw) To: Joe Buck; +Cc: Ziemowit Laski, Joseph S. Myers, gcc --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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-19 14:03 ` Mark Mitchell ` (3 preceding siblings ...) 2001-11-27 15:32 ` Mark Mitchell @ 2001-12-04 0:14 ` Alex Rosenberg 2001-12-04 0:33 ` Mark Mitchell 2001-12-04 11:25 ` Aldy Hernandez 4 siblings, 2 replies; 229+ messages in thread From: Alex Rosenberg @ 2001-12-04 0:14 UTC (permalink / raw) To: Mark Mitchell Cc: Ziemowit Laski, Joseph S. Myers, Aldy Hernandez, Joe Buck, egcs (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. | ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-12-04 0:14 ` Alex Rosenberg @ 2001-12-04 0:33 ` Mark Mitchell 2001-12-04 11:25 ` Aldy Hernandez 1 sibling, 0 replies; 229+ messages in thread From: Mark Mitchell @ 2001-12-04 0:33 UTC (permalink / raw) To: Alex Rosenberg Cc: Ziemowit Laski, Joseph S. Myers, Aldy Hernandez, Joe Buck, egcs > 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-12-04 0:14 ` Alex Rosenberg 2001-12-04 0:33 ` Mark Mitchell @ 2001-12-04 11:25 ` Aldy Hernandez 1 sibling, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-12-04 11:25 UTC (permalink / raw) To: Alex Rosenberg Cc: Mark Mitchell, Ziemowit Laski, Joseph S. Myers, Joe Buck, egcs > 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for 2001-11-19 11:55 ` Target-specific Front-Ends? (Was: front end changes for Joe Buck 2001-11-19 14:03 ` Mark Mitchell @ 2001-11-27 14:53 ` Joe Buck 1 sibling, 0 replies; 229+ messages in thread From: Joe Buck @ 2001-11-27 14:53 UTC (permalink / raw) To: Mark Mitchell; +Cc: Ziemowit Laski, Joseph S. Myers, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes foraltivec) 2001-11-19 10:23 ` Mark Mitchell 2001-11-19 11:55 ` Target-specific Front-Ends? (Was: front end changes for Joe Buck @ 2001-11-27 14:36 ` Mark Mitchell 1 sibling, 0 replies; 229+ messages in thread From: Mark Mitchell @ 2001-11-27 14:36 UTC (permalink / raw) To: Ziemowit Laski, Joseph S. Myers; +Cc: gcc > 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 7:56 ` Ziemowit Laski 2001-11-19 8:31 ` Richard Henderson 2001-11-19 10:23 ` Mark Mitchell @ 2001-11-27 13:19 ` Ziemowit Laski 2 siblings, 0 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-27 13:19 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 7:13 ` Joseph S. Myers 2001-11-19 7:34 ` Stan Shebs 2001-11-19 7:56 ` Ziemowit Laski @ 2001-11-27 12:44 ` Joseph S. Myers 2 siblings, 0 replies; 229+ messages in thread From: Joseph S. Myers @ 2001-11-27 12:44 UTC (permalink / raw) To: Ziemowit Laski; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 6:19 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski 2001-11-19 7:13 ` Joseph S. Myers @ 2001-11-19 8:34 ` Aldy Hernandez 2001-11-19 12:54 ` Stan Shebs 2001-11-27 13:44 ` Aldy Hernandez 2001-11-19 9:26 ` Bernd Schmidt ` (2 subsequent siblings) 4 siblings, 2 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-19 8:34 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Stan Shebs, Ira Ruben, gcc >>>>> "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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 8:34 ` Aldy Hernandez @ 2001-11-19 12:54 ` Stan Shebs 2001-11-19 15:41 ` Aldy Hernandez 2001-11-27 15:06 ` Stan Shebs 2001-11-27 13:44 ` Aldy Hernandez 1 sibling, 2 replies; 229+ messages in thread From: Stan Shebs @ 2001-11-19 12:54 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Ziemowit Laski, Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 12:54 ` Stan Shebs @ 2001-11-19 15:41 ` Aldy Hernandez 2001-11-19 19:08 ` Dale Johannesen 2001-11-27 16:56 ` Aldy Hernandez 2001-11-27 15:06 ` Stan Shebs 1 sibling, 2 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-19 15:41 UTC (permalink / raw) To: Stan Shebs; +Cc: Ziemowit Laski, Ira Ruben, gcc > 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 15:41 ` Aldy Hernandez @ 2001-11-19 19:08 ` Dale Johannesen 2001-11-19 19:15 ` Aldy Hernandez 2001-11-27 17:06 ` Dale Johannesen 2001-11-27 16:56 ` Aldy Hernandez 1 sibling, 2 replies; 229+ messages in thread From: Dale Johannesen @ 2001-11-19 19:08 UTC (permalink / raw) To: Aldy Hernandez Cc: Dale Johannesen, Stan Shebs, Ziemowit Laski, Ira Ruben, gcc > 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"? ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 19:08 ` Dale Johannesen @ 2001-11-19 19:15 ` Aldy Hernandez 2001-11-27 17:10 ` Aldy Hernandez 2001-11-27 17:06 ` Dale Johannesen 1 sibling, 1 reply; 229+ messages in thread From: Aldy Hernandez @ 2001-11-19 19:15 UTC (permalink / raw) To: Dale Johannesen; +Cc: Stan Shebs, Ziemowit Laski, Ira Ruben, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 19:15 ` Aldy Hernandez @ 2001-11-27 17:10 ` Aldy Hernandez 0 siblings, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-27 17:10 UTC (permalink / raw) To: Dale Johannesen; +Cc: Stan Shebs, Ziemowit Laski, Ira Ruben, gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 19:08 ` Dale Johannesen 2001-11-19 19:15 ` Aldy Hernandez @ 2001-11-27 17:06 ` Dale Johannesen 1 sibling, 0 replies; 229+ messages in thread From: Dale Johannesen @ 2001-11-27 17:06 UTC (permalink / raw) To: Aldy Hernandez Cc: Dale Johannesen, Stan Shebs, Ziemowit Laski, Ira Ruben, gcc > 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"? ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 15:41 ` Aldy Hernandez 2001-11-19 19:08 ` Dale Johannesen @ 2001-11-27 16:56 ` Aldy Hernandez 1 sibling, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-27 16:56 UTC (permalink / raw) To: Stan Shebs; +Cc: Ziemowit Laski, Ira Ruben, gcc > 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 12:54 ` Stan Shebs 2001-11-19 15:41 ` Aldy Hernandez @ 2001-11-27 15:06 ` Stan Shebs 1 sibling, 0 replies; 229+ messages in thread From: Stan Shebs @ 2001-11-27 15:06 UTC (permalink / raw) To: Aldy Hernandez; +Cc: Ziemowit Laski, Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 8:34 ` Aldy Hernandez 2001-11-19 12:54 ` Stan Shebs @ 2001-11-27 13:44 ` Aldy Hernandez 1 sibling, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-27 13:44 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Stan Shebs, Ira Ruben, gcc >>>>> "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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 6:19 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski 2001-11-19 7:13 ` Joseph S. Myers 2001-11-19 8:34 ` Aldy Hernandez @ 2001-11-19 9:26 ` Bernd Schmidt 2001-11-19 9:53 ` Ziemowit Laski 2001-11-27 14:13 ` Bernd Schmidt 2001-11-19 9:40 ` Stan Shebs 2001-11-27 12:24 ` Ziemowit Laski 4 siblings, 2 replies; 229+ messages in thread From: Bernd Schmidt @ 2001-11-19 9:26 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Stan Shebs, Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 9:26 ` Bernd Schmidt @ 2001-11-19 9:53 ` Ziemowit Laski 2001-11-19 10:59 ` Bernd Schmidt 2001-11-27 14:30 ` Ziemowit Laski 2001-11-27 14:13 ` Bernd Schmidt 1 sibling, 2 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-19 9:53 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Stan Shebs, Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 9:53 ` Ziemowit Laski @ 2001-11-19 10:59 ` Bernd Schmidt 2001-11-19 14:12 ` Ziemowit Laski 2001-11-27 14:41 ` Bernd Schmidt 2001-11-27 14:30 ` Ziemowit Laski 1 sibling, 2 replies; 229+ messages in thread From: Bernd Schmidt @ 2001-11-19 10:59 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Stan Shebs, Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 10:59 ` Bernd Schmidt @ 2001-11-19 14:12 ` Ziemowit Laski 2001-11-27 15:37 ` Ziemowit Laski 2001-11-27 14:41 ` Bernd Schmidt 1 sibling, 1 reply; 229+ messages in thread From: Ziemowit Laski @ 2001-11-19 14:12 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Stan Shebs, Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 14:12 ` Ziemowit Laski @ 2001-11-27 15:37 ` Ziemowit Laski 0 siblings, 0 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-27 15:37 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Stan Shebs, Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 10:59 ` Bernd Schmidt 2001-11-19 14:12 ` Ziemowit Laski @ 2001-11-27 14:41 ` Bernd Schmidt 1 sibling, 0 replies; 229+ messages in thread From: Bernd Schmidt @ 2001-11-27 14:41 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Stan Shebs, Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 9:53 ` Ziemowit Laski 2001-11-19 10:59 ` Bernd Schmidt @ 2001-11-27 14:30 ` Ziemowit Laski 1 sibling, 0 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-27 14:30 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Stan Shebs, Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 9:26 ` Bernd Schmidt 2001-11-19 9:53 ` Ziemowit Laski @ 2001-11-27 14:13 ` Bernd Schmidt 1 sibling, 0 replies; 229+ messages in thread From: Bernd Schmidt @ 2001-11-27 14:13 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Stan Shebs, Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 6:19 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski ` (2 preceding siblings ...) 2001-11-19 9:26 ` Bernd Schmidt @ 2001-11-19 9:40 ` Stan Shebs 2001-11-19 11:27 ` Ziemowit Laski 2001-11-27 14:20 ` Stan Shebs 2001-11-27 12:24 ` Ziemowit Laski 4 siblings, 2 replies; 229+ messages in thread From: Stan Shebs @ 2001-11-19 9:40 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 9:40 ` Stan Shebs @ 2001-11-19 11:27 ` Ziemowit Laski 2001-11-27 14:50 ` Ziemowit Laski 2001-11-27 14:20 ` Stan Shebs 1 sibling, 1 reply; 229+ messages in thread From: Ziemowit Laski @ 2001-11-19 11:27 UTC (permalink / raw) To: Stan Shebs; +Cc: Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 11:27 ` Ziemowit Laski @ 2001-11-27 14:50 ` Ziemowit Laski 0 siblings, 0 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-27 14:50 UTC (permalink / raw) To: Stan Shebs; +Cc: Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 9:40 ` Stan Shebs 2001-11-19 11:27 ` Ziemowit Laski @ 2001-11-27 14:20 ` Stan Shebs 1 sibling, 0 replies; 229+ messages in thread From: Stan Shebs @ 2001-11-27 14:20 UTC (permalink / raw) To: Ziemowit Laski; +Cc: Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-19 6:19 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski ` (3 preceding siblings ...) 2001-11-19 9:40 ` Stan Shebs @ 2001-11-27 12:24 ` Ziemowit Laski 4 siblings, 0 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-27 12:24 UTC (permalink / raw) To: Stan Shebs; +Cc: Ira Ruben, gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-18 23:55 ` Stan Shebs 2001-11-19 4:18 ` Ira Ruben 2001-11-19 6:19 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski @ 2001-11-27 9:48 ` Stan Shebs 2 siblings, 0 replies; 229+ messages in thread From: Stan Shebs @ 2001-11-27 9:48 UTC (permalink / raw) To: Ira Ruben; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes foraltivec) 2001-11-18 9:13 ` Ira Ruben ` (2 preceding siblings ...) 2001-11-18 23:55 ` Stan Shebs @ 2001-11-26 23:45 ` Ira Ruben 3 siblings, 0 replies; 229+ messages in thread From: Ira Ruben @ 2001-11-26 23:45 UTC (permalink / raw) To: Stan Shebs; +Cc: Ziemowit Laski, gcc, Aldy Hernandez, Joseph S. Myers 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-18 8:19 ` Stan Shebs 2001-11-18 9:13 ` Ira Ruben @ 2001-11-26 22:22 ` Stan Shebs 1 sibling, 0 replies; 229+ messages in thread From: Stan Shebs @ 2001-11-26 22:22 UTC (permalink / raw) To: Ziemowit Laski; +Cc: gcc, Aldy Hernandez, Joseph S. Myers 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Target-specific Front-Ends? (Was: front end changes for altivec) 2001-11-18 6:40 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski 2001-11-18 6:33 ` Aldy Hernandez 2001-11-18 8:19 ` Stan Shebs @ 2001-11-26 18:47 ` Ziemowit Laski 2 siblings, 0 replies; 229+ messages in thread From: Ziemowit Laski @ 2001-11-26 18:47 UTC (permalink / raw) To: gcc; +Cc: Aldy Hernandez, Joseph S. Myers 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: front end changes for altivec 2001-11-18 3:56 ` Joseph S. Myers 2001-11-18 4:24 ` Aldy Hernandez 2001-11-18 6:40 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski @ 2001-11-26 15:45 ` Joseph S. Myers 2 siblings, 0 replies; 229+ messages in thread From: Joseph S. Myers @ 2001-11-26 15:45 UTC (permalink / raw) To: Aldy Hernandez; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 229+ messages in thread
* front end changes for altivec 2001-11-16 9:10 front end changes for altivec Aldy Hernandez 2001-11-16 9:25 ` Andreas Jaeger 2001-11-18 3:56 ` Joseph S. Myers @ 2001-11-26 2:51 ` Aldy Hernandez 2 siblings, 0 replies; 229+ messages in thread From: Aldy Hernandez @ 2001-11-26 2:51 UTC (permalink / raw) To: gcc 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. ^ permalink raw reply [flat|nested] 229+ messages in thread
end of thread, other threads:[~2001-12-04 19:25 UTC | newest] Thread overview: 229+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-11-16 9:10 front end changes for altivec Aldy Hernandez 2001-11-16 9:25 ` Andreas Jaeger 2001-11-26 2:55 ` Andreas Jaeger 2001-11-18 3:56 ` Joseph S. Myers 2001-11-18 4:24 ` Aldy Hernandez 2001-11-18 5:09 ` Joseph S. Myers 2001-11-18 6:10 ` Aldy Hernandez 2001-11-18 7:35 ` Richard Henderson 2001-11-26 19:50 ` Richard Henderson 2001-11-26 18:19 ` Aldy Hernandez 2001-11-18 12:41 ` Aldy Hernandez 2001-11-18 13:38 ` Andreas Jaeger 2001-11-18 15:32 ` Aldy Hernandez 2001-11-18 16:49 ` Bernd Schmidt 2001-11-18 17:06 ` Aldy Hernandez 2001-11-27 8:29 ` Aldy Hernandez 2001-11-27 8:00 ` Bernd Schmidt 2001-11-27 7:55 ` Aldy Hernandez 2001-11-27 7:50 ` Andreas Jaeger 2001-11-19 8:02 ` Richard Henderson 2001-11-19 8:35 ` Aldy Hernandez 2001-11-19 9:19 ` Richard Henderson 2001-11-19 11:51 ` Stan Shebs 2001-11-19 13:41 ` Richard Henderson 2001-11-19 16:13 ` Aldy Hernandez 2001-11-19 17:51 ` Richard Henderson 2001-11-19 19:15 ` Aldy Hernandez 2001-11-19 20:50 ` Richard Henderson 2001-11-27 17:14 ` Richard Henderson 2001-11-27 17:10 ` Aldy Hernandez 2001-11-21 13:08 ` Alexandre Oliva 2001-11-21 13:12 ` Daniel Berlin 2001-11-21 13:29 ` Alexandre Oliva 2001-11-21 13:31 ` Daniel Berlin 2001-11-21 13:41 ` Jack Lloyd 2001-11-28 23:44 ` Jack Lloyd 2001-11-28 23:00 ` Daniel Berlin 2001-11-28 22:34 ` Alexandre Oliva 2001-11-21 13:33 ` Richard Henderson 2001-11-21 13:49 ` Daniel Berlin 2001-11-29 4:45 ` Daniel Berlin 2001-11-28 23:16 ` Richard Henderson 2001-11-28 22:21 ` Daniel Berlin 2001-11-21 13:24 ` Per Bothner 2001-11-28 22:25 ` Per Bothner 2001-11-28 21:07 ` Alexandre Oliva 2001-11-27 17:03 ` Richard Henderson 2001-11-27 16:57 ` Aldy Hernandez 2001-11-27 15:16 ` Richard Henderson 2001-11-27 14:50 ` Stan Shebs 2001-11-19 15:25 ` Aldy Hernandez 2001-11-19 17:46 ` Richard Henderson 2001-11-19 21:39 ` Aldy Hernandez 2001-11-20 1:05 ` Dale Johannesen 2001-11-20 2:23 ` Richard Henderson 2001-11-27 17:45 ` Richard Henderson 2001-11-27 17:40 ` Dale Johannesen 2001-11-20 2:46 ` Richard Henderson 2001-11-20 2:56 ` front end changes for altivec-- conclusion Aldy Hernandez 2001-11-27 18:00 ` Aldy Hernandez 2001-11-27 17:50 ` front end changes for altivec Richard Henderson 2001-11-27 17:24 ` Aldy Hernandez 2001-11-27 17:02 ` Richard Henderson 2001-11-27 16:50 ` Aldy Hernandez 2001-11-27 14:01 ` Richard Henderson 2001-11-27 13:52 ` Aldy Hernandez 2001-11-27 13:40 ` Richard Henderson 2001-11-27 7:24 ` Aldy Hernandez 2001-11-26 17:04 ` Joseph S. Myers 2001-11-26 16:39 ` Aldy Hernandez 2001-11-18 6:40 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski 2001-11-18 6:33 ` Aldy Hernandez 2001-11-26 18:46 ` Aldy Hernandez 2001-11-18 8:19 ` Stan Shebs 2001-11-18 9:13 ` Ira Ruben 2001-11-18 12:26 ` Aldy Hernandez 2001-11-19 4:45 ` Ira Ruben 2001-11-19 6:04 ` Geoff Keating 2001-11-19 7:28 ` Ira Ruben 2001-11-19 12:04 ` Phil Edwards 2001-11-27 14:58 ` Phil Edwards 2001-11-27 12:47 ` Ira Ruben 2001-11-27 12:10 ` Geoff Keating 2001-11-19 7:50 ` Aldy Hernandez 2001-11-27 13:12 ` Aldy Hernandez 2001-11-27 10:53 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Ira Ruben 2001-11-19 6:26 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski 2001-11-19 7:53 ` Aldy Hernandez 2001-11-19 7:56 ` Ziemowit Laski 2001-11-27 13:21 ` Ziemowit Laski 2001-11-27 13:13 ` Aldy Hernandez 2001-11-27 12:41 ` Ziemowit Laski 2001-11-27 6:46 ` Aldy Hernandez 2001-11-18 18:51 ` Per Bothner 2001-11-27 9:20 ` Per Bothner 2001-11-18 23:55 ` Stan Shebs 2001-11-19 4:18 ` Ira Ruben 2001-11-19 4:48 ` Per Bothner 2001-11-19 5:28 ` Daniel Berlin 2001-11-27 11:35 ` Daniel Berlin 2001-11-19 6:26 ` Ziemowit Laski 2001-11-20 0:33 ` Per Bothner 2001-11-20 3:16 ` Ziemowit Laski 2001-11-20 6:33 ` Per Bothner 2001-11-27 18:27 ` Per Bothner 2001-11-20 11:05 ` Stan Shebs 2001-11-27 18:35 ` Stan Shebs 2001-11-27 18:06 ` Ziemowit Laski 2001-11-20 3:19 ` Stan Shebs 2001-11-20 5:25 ` Joseph S. Myers 2001-11-27 18:24 ` Joseph S. Myers 2001-11-20 11:27 ` Per Bothner 2001-11-27 19:59 ` Per Bothner 2001-11-20 11:37 ` Mark Mitchell 2001-11-20 17:03 ` Aldy Hernandez 2001-11-20 18:25 ` Mark Mitchell 2001-11-28 9:45 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Mark Mitchell 2001-11-28 7:11 ` Target-specific Front-Ends? (Was: front end changes for altivec) Aldy Hernandez 2001-11-20 19:20 ` Stan Shebs 2001-11-20 20:24 ` Mark Mitchell 2001-11-20 23:47 ` Target-specific Front-Ends? (Was: front end changes for Joe Buck 2001-11-28 12:43 ` Joe Buck 2001-11-28 11:31 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Mark Mitchell 2001-11-20 20:27 ` Target-specific Front-Ends? (Was: front end changes for altivec) Dale Johannesen 2001-11-20 20:38 ` Stan Shebs 2001-11-21 4:47 ` Syd Polk 2001-11-21 12:31 ` Tim Hollebeek 2001-11-28 16:15 ` Tim Hollebeek 2001-11-28 14:12 ` Syd Polk 2001-11-28 11:55 ` Stan Shebs 2001-11-28 11:44 ` Dale Johannesen 2001-11-28 11:19 ` Stan Shebs 2001-11-27 20:40 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Mark Mitchell 2001-11-27 18:09 ` Target-specific Front-Ends? (Was: front end changes for altivec) Stan Shebs 2001-11-27 17:35 ` Per Bothner 2001-11-27 12:34 ` Ziemowit Laski 2001-11-27 11:16 ` Per Bothner 2001-11-27 10:47 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Ira Ruben 2001-11-19 6:19 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski 2001-11-19 7:13 ` Joseph S. Myers 2001-11-19 7:34 ` Stan Shebs 2001-11-19 8:01 ` Joseph S. Myers 2001-11-19 9:18 ` Aldy Hernandez 2001-11-19 11:23 ` Dale Johannesen 2001-11-27 14:46 ` Dale Johannesen 2001-11-27 13:56 ` Aldy Hernandez 2001-11-27 13:27 ` Joseph S. Myers 2001-11-27 12:57 ` Stan Shebs 2001-11-19 7:56 ` Ziemowit Laski 2001-11-19 8:31 ` Richard Henderson 2001-11-27 13:44 ` Richard Henderson 2001-11-19 10:23 ` Mark Mitchell 2001-11-19 11:55 ` Target-specific Front-Ends? (Was: front end changes for Joe Buck 2001-11-19 14:03 ` Mark Mitchell 2001-11-19 14:46 ` Joe Buck 2001-11-27 16:13 ` Joe Buck 2001-11-20 0:56 ` Devang Patel 2001-11-27 17:37 ` Devang Patel 2001-11-20 5:17 ` Aldy Hernandez 2001-11-20 11:15 ` Ziemowit Laski 2001-11-20 17:09 ` Aldy Hernandez 2001-11-20 17:26 ` Joe Buck 2001-11-20 17:57 ` Aldy Hernandez 2001-11-20 19:16 ` Neil Booth 2001-11-20 21:10 ` Input Stream Rewriting (Was: Target-specific Front-Ends?) Ziemowit Laski 2001-11-21 0:24 ` Neil Booth 2001-11-21 1:05 ` Ziemowit Laski 2001-11-21 4:38 ` Neil Booth 2001-11-28 13:57 ` Neil Booth 2001-11-28 13:25 ` Ziemowit Laski 2001-11-28 12:45 ` Neil Booth 2001-11-28 12:01 ` Ziemowit Laski 2001-11-28 11:06 ` Target-specific Front-Ends? (Was: front end changes for Neil Booth 2001-11-28 9:16 ` Aldy Hernandez 2001-11-28 9:11 ` Joe Buck 2001-11-20 20:53 ` Ziemowit Laski 2001-11-20 22:08 ` Joe Buck 2001-11-28 12:26 ` Joe Buck 2001-11-20 23:37 ` Per Bothner 2001-11-21 3:14 ` Ziemowit Laski 2001-11-21 12:32 ` David Edelsohn 2001-11-21 12:44 ` Ziemowit Laski 2001-11-28 18:40 ` Ziemowit Laski 2001-11-28 18:29 ` David Edelsohn 2001-11-28 13:36 ` Ziemowit Laski 2001-11-28 12:36 ` Per Bothner 2001-11-28 11:55 ` Ziemowit Laski 2001-11-28 7:33 ` Aldy Hernandez 2001-11-27 19:40 ` Ziemowit Laski 2001-11-20 19:17 ` Devang Patel 2001-11-28 11:09 ` Devang Patel 2001-11-27 18:21 ` Aldy Hernandez 2001-11-27 15:32 ` Mark Mitchell 2001-12-04 0:14 ` Alex Rosenberg 2001-12-04 0:33 ` Mark Mitchell 2001-12-04 11:25 ` Aldy Hernandez 2001-11-27 14:53 ` Joe Buck 2001-11-27 14:36 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Mark Mitchell 2001-11-27 13:19 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski 2001-11-27 12:44 ` Joseph S. Myers 2001-11-19 8:34 ` Aldy Hernandez 2001-11-19 12:54 ` Stan Shebs 2001-11-19 15:41 ` Aldy Hernandez 2001-11-19 19:08 ` Dale Johannesen 2001-11-19 19:15 ` Aldy Hernandez 2001-11-27 17:10 ` Aldy Hernandez 2001-11-27 17:06 ` Dale Johannesen 2001-11-27 16:56 ` Aldy Hernandez 2001-11-27 15:06 ` Stan Shebs 2001-11-27 13:44 ` Aldy Hernandez 2001-11-19 9:26 ` Bernd Schmidt 2001-11-19 9:53 ` Ziemowit Laski 2001-11-19 10:59 ` Bernd Schmidt 2001-11-19 14:12 ` Ziemowit Laski 2001-11-27 15:37 ` Ziemowit Laski 2001-11-27 14:41 ` Bernd Schmidt 2001-11-27 14:30 ` Ziemowit Laski 2001-11-27 14:13 ` Bernd Schmidt 2001-11-19 9:40 ` Stan Shebs 2001-11-19 11:27 ` Ziemowit Laski 2001-11-27 14:50 ` Ziemowit Laski 2001-11-27 14:20 ` Stan Shebs 2001-11-27 12:24 ` Ziemowit Laski 2001-11-27 9:48 ` Stan Shebs 2001-11-26 23:45 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Ira Ruben 2001-11-26 22:22 ` Target-specific Front-Ends? (Was: front end changes for altivec) Stan Shebs 2001-11-26 18:47 ` Ziemowit Laski 2001-11-26 15:45 ` front end changes for altivec Joseph S. Myers 2001-11-26 2:51 ` Aldy Hernandez
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).