From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1520 invoked by alias); 27 Nov 2001 22:50:28 -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 1481 invoked from network); 27 Nov 2001 22:50:28 -0000 Received: from unknown (HELO mail-out1.apple.com) (17.254.0.52) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 22:50:28 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id fARMoRu11310 for ; Tue, 27 Nov 2001 14:50:27 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 27 Nov 2001 14:50:26 -0800 Received: from gourd (gourd.apple.com [17.202.44.182]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id fARMoPH23765; Tue, 27 Nov 2001 14:50:25 -0800 (PST) Date: Mon, 19 Nov 2001 11:27:00 -0000 Subject: Re: 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 v475) Cc: Ira Ruben , gcc@gcc.gnu.org To: Stan Shebs From: Ziemowit Laski In-Reply-To: <3C041193.DBC0A69@apple.com> Message-Id: <2535A65A-E389-11D5-AE62-0030658361CA@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.475) X-SW-Source: 2001-11/txt/msg00902.txt.bz2 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ziemowit Laski To: Stan Shebs Cc: Ira Ruben , gcc@gcc.gnu.org Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec) Date: Tue, 27 Nov 2001 14:50:00 -0000 Message-ID: <2535A65A-E389-11D5-AE62-0030658361CA@apple.com> References: <3C041193.DBC0A69@apple.com> X-SW-Source: 2001-11/msg01403.html Message-ID: <20011127145000.PPH1ZYrMXakXgdke9fjLbF67YQp9fepRKz6geutS7ho@z> 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