From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2216 invoked by alias); 27 Nov 2001 02:47:32 -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 2166 invoked from network); 27 Nov 2001 02:47:28 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 02:47:28 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id fAR2R1X09730 for ; Mon, 26 Nov 2001 18:27:01 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 26 Nov 2001 18:26:46 -0800 Received: from gourd (gourd.apple.com [17.202.44.182]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id fAR2Qjh20895; Mon, 26 Nov 2001 18:26:45 -0800 (PST) Date: Sun, 18 Nov 2001 06:40:00 -0000 Subject: Target-specific Front-Ends? (Was: front end changes for altivec) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v472) Cc: Aldy Hernandez , "Joseph S. Myers" To: gcc@gcc.gnu.org From: Ziemowit Laski In-Reply-To: Message-Id: <339DE634-E2DE-11D5-A770-0030658361CA@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.472) X-SW-Source: 2001-11/txt/msg00813.txt.bz2 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ziemowit Laski To: gcc@gcc.gnu.org Cc: Aldy Hernandez , "Joseph S. Myers" Subject: Target-specific Front-Ends? (Was: front end changes for altivec) Date: Mon, 26 Nov 2001 18:47:00 -0000 Message-ID: <339DE634-E2DE-11D5-A770-0030658361CA@apple.com> References: X-SW-Source: 2001-11/msg01317.html Message-ID: <20011126184700.zWK7tNpPou5nBG9X67X3bx-PIrERlESNKRjIypH_DbM@z> 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