From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11276 invoked by alias); 27 Nov 2001 06:22:57 -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 11250 invoked from network); 27 Nov 2001 06:22:55 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 06:22:55 -0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id fAR6MtX28658 for ; Mon, 26 Nov 2001 22:22:55 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 26 Nov 2001 22:22:25 -0800 Received: from apple.com (vpn-gh-550.apple.com [17.254.138.37]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id fAR6McG25880; Mon, 26 Nov 2001 22:22:38 -0800 (PST) Message-ID: <3C033117.F8EDD78A@apple.com> Date: Sun, 18 Nov 2001 08:19:00 -0000 From: Stan Shebs X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Ziemowit Laski CC: gcc@gcc.gnu.org, Aldy Hernandez , "Joseph S. Myers" Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec) References: <339DE634-E2DE-11D5-A770-0030658361CA@apple.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-SW-Source: 2001-11/txt/msg00819.txt.bz2 Ziemowit Laski wrote: > > 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') When you put it that way, my general reaction is to say "bleah". :-) GCC philosophy has never been to implement every feature ever seen in somebody else's compiler, but instead to have a single compiler that behaves consistently across a range of architectures and operating systems. There are frontend extension mechanisms, such as pragmas and attributes for C dialects for instance, as well as builtin functions, so there is plenty to work with already. It may be that these are inadequate, but the case would have to be pretty compelling on technical grounds. For instance, in the case of AltiVec extensions, the effect of vector/pixel keywords can be almost entirely achieved with mode attributes, the overloaded builtins could be handled by adding a general concept of overloaded builtins, leaving only the vector constant syntax as an oddball. From what I know of the AltiVec- using population, the total aggregate effort of changing the syntax of all the vector constants in source code might add up to as much as one day - less than the effort needed to get the extension working in GCC. So should we implement the extension and support it forever, or get users to spend a few minutes to change their sources? The moral of the story with respect to AltiVec is that GNU people should try to be more involved when new technologies are being introduced. As far as I know (I admit to being out of the loop myself), the AltiVec programming model was designed by a group working on various proprietary compilers, and the question of GCC support didn't come up until later. There were some real boners, such as the context sensitivity of the vector keyword, that I think could have been avoided if some GCC folks had participated. It's easy to say "oh, I can't do anything without having a signed contract first" or "why should I care about PowerPC/x86/ARM/etc", but in cases like these some upfront interest and nosiness will pay off in the long run; we can then spend our development time on improvements that benefit everybody, rather than tricky hacks to support another limited-interest target-specific extension. Stan From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stan Shebs To: Ziemowit Laski Cc: gcc@gcc.gnu.org, Aldy Hernandez , "Joseph S. Myers" Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec) Date: Mon, 26 Nov 2001 22:22:00 -0000 Message-ID: <3C033117.F8EDD78A@apple.com> References: <339DE634-E2DE-11D5-A770-0030658361CA@apple.com> X-SW-Source: 2001-11/msg01323.html Message-ID: <20011126222200.YErRP8ih9UAD74lQ6V5NO5g5z7baXVm1ydbYR3hpv4E@z> Ziemowit Laski wrote: > > 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') When you put it that way, my general reaction is to say "bleah". :-) GCC philosophy has never been to implement every feature ever seen in somebody else's compiler, but instead to have a single compiler that behaves consistently across a range of architectures and operating systems. There are frontend extension mechanisms, such as pragmas and attributes for C dialects for instance, as well as builtin functions, so there is plenty to work with already. It may be that these are inadequate, but the case would have to be pretty compelling on technical grounds. For instance, in the case of AltiVec extensions, the effect of vector/pixel keywords can be almost entirely achieved with mode attributes, the overloaded builtins could be handled by adding a general concept of overloaded builtins, leaving only the vector constant syntax as an oddball. From what I know of the AltiVec- using population, the total aggregate effort of changing the syntax of all the vector constants in source code might add up to as much as one day - less than the effort needed to get the extension working in GCC. So should we implement the extension and support it forever, or get users to spend a few minutes to change their sources? The moral of the story with respect to AltiVec is that GNU people should try to be more involved when new technologies are being introduced. As far as I know (I admit to being out of the loop myself), the AltiVec programming model was designed by a group working on various proprietary compilers, and the question of GCC support didn't come up until later. There were some real boners, such as the context sensitivity of the vector keyword, that I think could have been avoided if some GCC folks had participated. It's easy to say "oh, I can't do anything without having a signed contract first" or "why should I care about PowerPC/x86/ARM/etc", but in cases like these some upfront interest and nosiness will pay off in the long run; we can then spend our development time on improvements that benefit everybody, rather than tricky hacks to support another limited-interest target-specific extension. Stan