From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16025 invoked by alias); 27 Nov 2001 16:00:10 -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 15989 invoked from network); 27 Nov 2001 16:00:08 -0000 Received: from unknown (HELO host140.cambridge.redhat.com) (195.224.55.237) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 16:00:08 -0000 Received: from localhost (bernds@localhost) by host140.cambridge.redhat.com (8.11.6/8.11.6) with ESMTP id fARFxQM01852; Tue, 27 Nov 2001 15:59:26 GMT X-Authentication-Warning: host140.cambridge.redhat.com: bernds owned process doing -bs Date: Sun, 18 Nov 2001 16:49:00 -0000 From: Bernd Schmidt X-X-Sender: To: Aldy Hernandez cc: Andreas Jaeger , "Joseph S. Myers" , Subject: Re: front end changes for altivec In-Reply-To: <1006876651.5637.14.camel@litecycle.cc.andrews.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2001-11/txt/msg00843.txt.bz2 On 27 Nov 2001, Aldy Hernandez wrote: > On Tue, 2001-11-27 at 09:50, Andreas Jaeger wrote: > > Aldy Hernandez 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernd Schmidt To: Aldy Hernandez Cc: Andreas Jaeger , "Joseph S. Myers" , Subject: Re: front end changes for altivec Date: Tue, 27 Nov 2001 08:00:00 -0000 Message-ID: References: <1006876651.5637.14.camel@litecycle.cc.andrews.edu> X-SW-Source: 2001-11/msg01347.html Message-ID: <20011127080000.wBSX9nJhfo8njiHSy48kXySaEp_cMQ-AlbjvUVI2eM0@z> On 27 Nov 2001, Aldy Hernandez wrote: > On Tue, 2001-11-27 at 09:50, Andreas Jaeger wrote: > > Aldy Hernandez 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