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