From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10337 invoked by alias); 27 Nov 2001 15:50:07 -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 10313 invoked from network); 27 Nov 2001 15:50:05 -0000 Received: from unknown (HELO Cantor.suse.de) (213.95.15.193) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 15:50:05 -0000 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 754801E56A; Tue, 27 Nov 2001 16:50:04 +0100 (MET) X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f Mail-Copies-To: never To: Aldy Hernandez Cc: "Joseph S. Myers" , gcc@gcc.gnu.org Subject: Re: front end changes for altivec References: <1006874643.5176.8.camel@litecycle.cc.andrews.edu> From: Andreas Jaeger Date: Sun, 18 Nov 2001 13:38:00 -0000 In-Reply-To: <1006874643.5176.8.camel@litecycle.cc.andrews.edu> (Aldy Hernandez's message of "27 Nov 2001 09:24:03 -0600") Message-ID: User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.4 (Artificial Intelligence, i386-suse-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2001-11/txt/msg00841.txt.bz2 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. 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Jaeger To: Aldy Hernandez Cc: "Joseph S. Myers" , gcc@gcc.gnu.org Subject: Re: front end changes for altivec Date: Tue, 27 Nov 2001 07:50:00 -0000 Message-ID: References: <1006874643.5176.8.camel@litecycle.cc.andrews.edu> X-SW-Source: 2001-11/msg01345.html Message-ID: <20011127075000.r7Ox3HF1ch9LzGRZEcFs_lz_8RBujZahWzqo-UMfybQ@z> 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. 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