From mboxrd@z Thu Jan  1 00:00:00 1970
From: dewar@gnat.com (Robert Dewar)
To: gdr@integrable-solutions.net, zack@codesourcery.com
Cc: gcc@gcc.gnu.org
Subject: Re: A FrontEnd in C++?
Date: Thu, 22 Aug 2002 14:53:00 -0000
Message-id: <20020822215341.DBAF5F2A5C@nile.gnat.com>
X-SW-Source: 2002-08/msg01361.html

> Under this constraint, I hope you'll agree with me that the thing to
> do is pick just one language, and write your compiler using the most
> minimal subset of that language that is practical, also avoiding as
> much of the runtime library as is practical.  Under this constraint,
> it is a desirable state of affairs that your step (2) above only
> exercises a small subset of the compiler you've written.  (Exercising
> the rest of the compiler is the function of the test suite.)


But the more common situation is that you can bootstrap the compiler using
some other compiler to do the first step. For example, GNAT was originally
bootstrapped using the Alsys compiler on the Sun, and Realia COBOL was
originally bootstrapped using IBM F Compiler on a 370/148.

In the case where you are doing a completely new language, there are other
approaches. For example, this last semester in my graduate compiler class
I had people write a compiler for an Algol-68 subset in Algol-68 generating
assembler code for MMIX, and to fully complete the assignment, students
had to do a full bootstrap with identity check.

About half the class successfully completed the entire bootstrap. Of this
group (about 15 people), half had used C-Front, a translator that translates
into C to get the initial bootstrap compiler, and half first wrote in hevaily
macroized C which could then be easily converted to Algol-68 by a mixture
of manual and automatic processing. Both approaches seem to be quite workable.

As another example, Alsys wrote their first Ada compiler in Ada, and used a very
crude and inefficient translator into PL/1 to get the bootstrap done.

> Now.  Based on historical evidence, I argue that that's not a thought
> experiment at all.  It is instead a slight exaggeration of the
> situation we are in, developing GCC.  We have a five-year track record
> of having to work around bugs in the C runtime and the bootstrap
> compiler.  I see no reason to expect this situation ever to change.
> Restricting ourselves to a safe subset of C and C only is a sensible
> way to insulate ourselves from these problems as best we can.

Actually it seems to me that the situation with the GCC C compiler is much
harder than usual as a result of the self inflicted additional hard requirement
that it be compilable on all C compilers. I must say that in the case of GNAT
we have had very little trouble in maintaining the bootstrap, and the same
was true in Realia COBOL.