This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: A FrontEnd in C++?


Zack Weinberg <zack@codesourcery.com> writes:

| On Mon, Aug 19, 2002 at 11:14:08AM +0200, Gabriel Dos Reis wrote:
| > | Based on the number of problems we have encountered with the Ada front
| > | end compared to the others, I think that as a matter of project policy
| > | writing front ends in any language other than C should be discouraged.
| > 
| > It is far from clear that those problems aren't deficiencies in the
| > GCC's own architecture; any project that would make it possible to use
| > the targetted language as an implementation language for front-ends
| > should be highly encouraged IMSHO.
| 
| It seems that many people are more sanguine about allowing front ends
| to be written in their own languages than I am.  I didn't properly
| explain why I don't like the idea; let me try again.

Sorry to follow-up so late, but I hate more pressing issues to sort out.

So back to why other non-C front-ends should use or not use C as the
implementation language in GCC.

| There is an intrinsic complexity burden to maintaining a program with
| components written in multiple languages. 

Certainly, there is an intrinsic complexity to maintain different
components written in different languages, that is not new.  But the
complexity can be managed, that also isn't new.

| You have to have a
| functional compiler and runtime library for each source language, for
| starters. 

That applies equally well to a front-end written in C or in the
implemented language.

| On top of that, all the languages have to be ABI
| compatible; 

No, that doesn't follow.  GNAT doesn't need to be ABI compatible with
gcc; it just needs to agree one (small) conventions of how trees (and
some related types and functions) are passed up/down.


What I find really scary about the current situation is exemplified as
follows:

  (1) one makes a C++-only change to cc1plus
  (2) bootstrap the compiler
  (3) regress test
  (4) submit with a clear note about the result of (2) and (3).

However, (2) doesn't really exercise cc1plus; it does exercise cc1.
Ahem.  One makes a change to cc1plus and goes on exercising cc1.
Were cc1plus written in C++, we would be exercising cc1plus after a
change to cc1plus.  Yes, certainly, one builds the library V3 -- but
it is just about small instantiations.

[...]

| I am not a priori opposed to reworking the *entire compiler* in a
| different language, although I think there are better things we could
| be spending our time on.

I'm not advocating rewriting cc1plus in C++ (I don't think anything
like that would ever happen to cc1plus) but I do think that efforts to
implement a front-end for GCC using the targetted languaged as an
implementation language should be encouraged.  Not just because some
damages were made to some front-ends means we should keep on damaging
new front-ends.  [ Sorry we disagree one more time. ]

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]