From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6222 invoked by alias); 27 Nov 2001 02:19:37 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 6133 invoked from network); 27 Nov 2001 02:19:30 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 02:19:30 -0000 Received: from taarna.cygnus.com (taarna.cygnus.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id RAA19319; Mon, 26 Nov 2001 17:50:04 -0800 (PST) From: Aldy Hernandez Received: (aldyh@localhost) by taarna.cygnus.com (SMI-8.6/8.6.4) id RAA28920; Mon, 26 Nov 2001 17:50:04 -0800 Message-ID: <20011126175004.26679@taarna.cygnus.com> Date: Sun, 18 Nov 2001 06:10:00 -0000 To: "Joseph S. Myers" Cc: Aldy Hernandez , Aldy Hernandez , gcc@gcc.gnu.org Subject: Re: front end changes for altivec References: <20011126163925.55335@taarna.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: ; from Joseph S. Myers on Tue, Nov 27, 2001 at 01:04:05AM +0000 X-SW-Source: 2001-11/txt/msg00811.txt.bz2 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aldy Hernandez To: "Joseph S. Myers" Cc: Aldy Hernandez , Aldy Hernandez , gcc@gcc.gnu.org Subject: Re: front end changes for altivec Date: Mon, 26 Nov 2001 18:19:00 -0000 Message-ID: <20011126175004.26679@taarna.cygnus.com> References: <20011126163925.55335@taarna.cygnus.com> X-SW-Source: 2001-11/msg01315.html Message-ID: <20011126181900.9AagzAMAXRRMFQqmu1Zakq0eqiQ9KF9M0AUh-wtpqy4@z> 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