A FrontEnd in C++?

A FrontEnd in C++?

[khalid aggag]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

I am currently developing a new Frontend for an educational language for 
GCC. I have the language's lexical analysis and parsing modules in C++. Is 
it possible to develop a frontend for gcc written completely in C++? How 
would I make up for the different function naming and calling conventions 
between C and C++? Thanx alot in advance.


Khalid Aggag


_________________________________________________________________
Join the worldÂ’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

Re: A FrontEnd in C++?

[Michael S. Zick]

On Saturday 17 August 2002 05:45 pm, khalid aggag wrote:
> I am currently developing a new Frontend for an educational language for
> GCC. I have the language's lexical analysis and parsing modules in C++. Is
> it possible to develop a frontend for gcc written completely in C++? How
> would I make up for the different function naming and calling conventions
> between C and C++? Thanx alot in advance.
>
>
> Khalid Aggag

Aside from the technical questions...
Have you considered the bootstrapping issues?

Originally, GCC could be bootstrapped with "any 'ol" C compiler.
Now, it can be bootstrapped with (almost) "any 'ol C compiler PLUS an Ada 
compiler that produces "link compatable" object files.

Writing a front end in C++ would make that process:

Stage0: any 'ol C compiler -> gcc<c, c++>
Stage1: gcc<c, c++> + new_frontend -> gcc<c, c++, New>
Stage2: gcc<c, c++, New> -> presumably_finished_compiler
Stage3: presumably_finished_compiler -> finished_compiler

Compare Stage2 with Stage3, if same; then done; else punt!

And just to make it more interesting - add bootstrapping Ada in the above 
process at the same time.

Mike

Re: A FrontEnd in C++?

[Fergus Henderson]

On 17-Aug-2002, khalid aggag <khalidaggag@hotmail.com> wrote:
> I am currently developing a new Frontend for an educational language for 
> GCC. I have the language's lexical analysis and parsing modules in C++. Is 
> it possible to develop a frontend for gcc written completely in C++?

Yes, it is possible.
People have written frontends for gcc in languages other than C before.
For example, the Ada front-end is written in Ada, and the Mercury
front-end is written in Mercury.  These both include a small amount
of C code to interface with the GCC back-end, but if you're writing
in C++ you should be able to avoid that.  You might need to make
some minor modifications to the GCC header files, though.

> How 
> would I make up for the different function naming and calling conventions 
> between C and C++? Thanx alot in advance.

Use `extern "C"', either in the C++ code, e.g.

	extern "C" {
	  #include "tree.h"
	}

or by modifying the GCC headers, e.g.

	/* tree.h */
	#ifdef __cplusplus
	extern "C" {
	#endif

	... body of tree.h goes here

	#ifdef __cplusplus
	}
	#endif

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: A FrontEnd in C++?

[Zack Weinberg]

On Mon, Aug 19, 2002 at 05:46:18PM +1000, Fergus Henderson wrote:
> On 17-Aug-2002, khalid aggag <khalidaggag@hotmail.com> wrote:
> > I am currently developing a new Frontend for an educational language for 
> > GCC. I have the language's lexical analysis and parsing modules in C++. Is 
> > it possible to develop a frontend for gcc written completely in C++?
> 
> Yes, it is possible.
> People have written frontends for gcc in languages other than C before.
> For example, the Ada front-end is written in Ada, and the Mercury
> front-end is written in Mercury. 

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.

zw

Re: A FrontEnd in C++?

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

| On Mon, Aug 19, 2002 at 05:46:18PM +1000, Fergus Henderson wrote:
| > On 17-Aug-2002, khalid aggag <khalidaggag@hotmail.com> wrote:
| > > I am currently developing a new Frontend for an educational language for 
| > > GCC. I have the language's lexical analysis and parsing modules in C++. Is 
| > > it possible to develop a frontend for gcc written completely in C++?
| > 
| > Yes, it is possible.
| > People have written frontends for gcc in languages other than C before.
| > For example, the Ada front-end is written in Ada, and the Mercury
| > front-end is written in Mercury. 
| 
| 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.

-- Gaby

Re: A FrontEnd in C++?

[Michael S. Zick]

On Monday 19 August 2002 04:14 am, Gabriel Dos Reis wrote:
> Zack Weinberg <zack@codesourcery.com> writes:
>
> 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.
>
I am currently rewriting the "install" directions, BUT...

As a "background task" pre-thinking those gcc-Makefiles...
I have gotten as far in the outline of their structure (to be) that I can 
agree with Gabriel - the first (stage0?) compiler should be buildable from 
and collection of multiple compilers (as far as the Makefiles are concerned 
that is).

First, though, I need to get the "install directions" caught up with the 
current situation before I out-date them with a different set of Makefiles.

Mike

Re: A FrontEnd in C++?

[Zack Weinberg]

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.

There is an intrinsic complexity burden to maintaining a program with
components written in multiple languages.  You have to have a
functional compiler and runtime library for each source language, for
starters.  On top of that, all the languages have to be ABI
compatible; historically, very little effort has been put into
maintaining that compatibility (beyond what is needed to interface the
language runtime to the system), so it is not a thing to be relied on.
Bugs due to deficiencies in the bootstrap compilers, or due to
cross-language ABI incompatibilities, are guaranteed to be hard to
find, since all the source code may be correct.

Never mind any additional burden due to deficiencies in GCC's
architecture, which there certainly are (all the C-specific stuff that
has to be stubbed out in other front ends, comes to mind).  Even if
all those problems were addressed, the intrinsic difficulties of
maintaining a program written in multiple languages would remain.  It
is my opinion that these intrinsic difficulties are *all by
themselves* sufficiently bad that we should avoid writing new code in
languages other than the currently predominant one, i.e. C.

I raised the Ada front end as an example, since it is the only front
end written in its own language currently present in the official GCC
tree.  I am certain that (for instance) a C++ front end written in C++
would have the same sorts of problems.  Robert Dewar asserts that
there have been no serious problems with the Ada front end - I would
like to remind him of the large number of "failure to bootstrap with
Ada enabled" PRs currently sitting unaddressed in GNATS: 6016, 6160,
6552, 6573, 6584, 6661, 6669, 6696, 6767, 6816, 6851, 6852, 6853,
6872, 6879, 6931, 6942, 7209, and 7337.  This is one way the intrinsic
complexity burden manifests itself - there are only a few people who
understand Ada well enough to fix bugs in the Ada front end.

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.

zw

Re: A FrontEnd in C++?

[Michael Matz]

Hi,

On Wed, 21 Aug 2002, Zack Weinberg wrote:

> > 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.

Although note, that the initial posting wasn't about adding a new frontend
written in it's own language, but simply written in C++, for which we
already have a frontend.  This has not the usual bootstrap problems.
While this doesn't provide the same testing for the new language, the
maintenace burden of this approach is far less.  Yes we (or better the
developer of that frontend) would need to ensure that he's interfacing
correctly with the backend, but that can be done with a rather small C
part, like e.g. Ada does it.


Ciao,
Michael.

Re: A FrontEnd in C++?

[Zack Weinberg]

On Wed, Aug 21, 2002 at 07:59:45PM +0200, Michael Matz wrote:
> >
> > It seems that many people are more sanguine about allowing front ends
> > to be written in their own languages than I am.
> 
> Although note, that the initial posting wasn't about adding a new frontend
> written in it's own language, but simply written in C++, for which we
> already have a frontend.  This has not the usual bootstrap problems.
> While this doesn't provide the same testing for the new language, the
> maintenace burden of this approach is far less.  Yes we (or better the
> developer of that frontend) would need to ensure that he's interfacing
> correctly with the backend, but that can be done with a rather small C
> part, like e.g. Ada does it.

No.  The intrinsic complexity burden I am talking about is exclusively
a function of the number of different languages used in the source
tree (ignoring runtime libraries).  It doesn't matter which bits are
written in which languages.

zw

Re: A FrontEnd in C++?

[Daniel Berlin]

On Wed, 21 Aug 2002, Zack Weinberg wrote:

> On Wed, Aug 21, 2002 at 07:59:45PM +0200, Michael Matz wrote:
> > >
> > > It seems that many people are more sanguine about allowing front ends
> > > to be written in their own languages than I am.
> > 
> > Although note, that the initial posting wasn't about adding a new frontend
> > written in it's own language, but simply written in C++, for which we
> > already have a frontend.  This has not the usual bootstrap problems.
> > While this doesn't provide the same testing for the new language, the
> > maintenace burden of this approach is far less.  Yes we (or better the
> > developer of that frontend) would need to ensure that he's interfacing
> > correctly with the backend, but that can be done with a rather small C
> > part, like e.g. Ada does it.
> 
> No.  The intrinsic complexity burden I am talking about is exclusively
> a function of the number of different languages used in the source
> tree (ignoring runtime libraries).  It doesn't matter which bits are
> written in which languages.
Then, in the case of a frontend written in C++, the complexity burden 
would not increase, since libstdc++ and libsupc++ are already written in 
C++ (as are parts of libjava, etc).
 > 
> zw
> 
> 

Re: A FrontEnd in C++?

[Michael Matz]

Hi,

On Wed, 21 Aug 2002, Daniel Berlin wrote:

> > No.  The intrinsic complexity burden I am talking about is exclusively
> > a function of the number of different languages used in the source
> > tree (ignoring runtime libraries).  It doesn't matter which bits are
> > written in which languages.
>
> Then, in the case of a frontend written in C++, the complexity burden
> would not increase, since libstdc++ and libsupc++ are already written in
> C++ (as are parts of libjava, etc).

Note, how Zack cleverly ruled out runtime libraries ;-)

I agree, that more languages mean more complexity, of course.  But IMHO
C++ is just so much more better suited for dealing with data structures,
that this feature nullifies the burden.  OTOH this all remains
theoretical, as long as there's no actual frontend written in C++ (or
whatever else).  If it pops up, we can value if it really adds too much
burden.


Ciao,
Michael.

P.S.: I even thought sometimes about (re)writing some of the optimizations
in C++.  So the stage1 compiler simply would miss some optimizations (as
it still would be translated with just the C compiler), and we would need
a four stage bootstrap.  But as most of the base data structures in the
backend would be needed to remain C, the value of this might be
questionable.

Re: A FrontEnd in C++?

[Daniel Berlin]

On Wed, 21 Aug 2002, Michael Matz wrote:

> Hi,
> 
> On Wed, 21 Aug 2002, Daniel Berlin wrote:
> 
> > > No.  The intrinsic complexity burden I am talking about is exclusively
> > > a function of the number of different languages used in the source
> > > tree (ignoring runtime libraries).  It doesn't matter which bits are
> > > written in which languages.
> >
> > Then, in the case of a frontend written in C++, the complexity burden
> > would not increase, since libstdc++ and libsupc++ are already written in
> > C++ (as are parts of libjava, etc).
> 
> Note, how Zack cleverly ruled out runtime libraries ;-)
> 
> I agree, that more languages mean more complexity, of course.  But IMHO
> C++ is just so much more better suited for dealing with data structures,
> that this feature nullifies the burden.

I so agree it's not even funny.
>   OTOH this all remains
> theoretical, as long as there's no actual frontend written in C++ (or
> whatever else).  If it pops up, we can value if it really adds too much
> burden.
> 
> 
> Ciao,
> Michael.
> 
> P.S.: I even thought sometimes about (re)writing some of the optimizations
> in C++.  

I've actually started doing it many times.
In particular, i've still got the start of an interprocedural middle-end 
(IE takes trees from many modules) written in C++.

You can't believe how nice it is to just simply be able to do things like 
std::set<tree>, etc.
It seems trivial, but it's really a lot nicer to work with classes.

--Dan

Re: A FrontEnd in C++?

[Pop Sébastian]

Hi,

On Wed, Aug 21, 2002 at 02:50:47PM -0400, Daniel Berlin wrote:
> > 
> > P.S.: I even thought sometimes about (re)writing some of the optimizations
> > in C++.  
> 
> I've actually started doing it many times.
> In particular, i've still got the start of an interprocedural middle-end 
> (IE takes trees from many modules) written in C++.
> 
> You can't believe how nice it is to just simply be able to do things like 
> std::set<tree>, etc.
> It seems trivial, but it's really a lot nicer to work with classes.
> 

Why not beginning to write the AST optimizer in C++?

The AST optimizer is not needed for building the C, nor the C++ compiler,
but once g++ is built we could build the AST optimizer.

This way we avoid to require a C++ compiler for building a part of GCC.

Re: A FrontEnd in C++?

[Diego Novillo]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

On Thu, 2002-08-22 at 16:03, Pop Sébastian wrote:

> On Wed, Aug 21, 2002 at 02:50:47PM -0400, Daniel Berlin wrote:
> > > 
> > > P.S.: I even thought sometimes about (re)writing some of the optimizations
> > > in C++.  
> > 
> > I've actually started doing it many times.
> > In particular, i've still got the start of an interprocedural middle-end 
> > (IE takes trees from many modules) written in C++.
> > 
> 
> Why not beginning to write the AST optimizer in C++?
> 
Go right ahead.  All you need is a new branch and some free time.  I
would personally suggest following some of the design and implementation
ideas from SUIF and/or Sage++.  They are kind of neat.


Diego.

Re: A FrontEnd in C++?

[Pop Sébastian]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

On Thu, Aug 22, 2002 at 04:11:02PM -0400, Diego Novillo wrote:
> On Thu, 2002-08-22 at 16:03, Pop Sébastian wrote:
> 
> > On Wed, Aug 21, 2002 at 02:50:47PM -0400, Daniel Berlin wrote:
> > > > 
> > > > P.S.: I even thought sometimes about (re)writing some of the optimizations
> > > > in C++.  
> > > 
> > > I've actually started doing it many times.
> > > In particular, i've still got the start of an interprocedural middle-end 
> > > (IE takes trees from many modules) written in C++.
> > > 
> > 
> > Why not beginning to write the AST optimizer in C++?
> > 
> Go right ahead.  All you need is a new branch and some free time.  I
> would personally suggest following some of the design and implementation
> ideas from SUIF and/or Sage++.  They are kind of neat.
> 

Thanks for this suggestion.

I thought also to SGI's open64 compiler on which I currently work.
Its architecture is composed of the C/C++ front-ends comming from GCC
and a back-end that uses the WHIRL representation.  The whole back-end 
is written in C++.

Re: A FrontEnd in C++?

[Daniel Berlin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

On Thu, 22 Aug 2002, [iso-8859-1] Pop Sébastian wrote:

> Hi,
> 
> On Wed, Aug 21, 2002 at 02:50:47PM -0400, Daniel Berlin wrote:
> > > 
> > > P.S.: I even thought sometimes about (re)writing some of the optimizations
> > > in C++.  
> > 
> > I've actually started doing it many times.
> > In particular, i've still got the start of an interprocedural middle-end 
> > (IE takes trees from many modules) written in C++.
> > 
> > You can't believe how nice it is to just simply be able to do things like 
> > std::set<tree>, etc.
> > It seems trivial, but it's really a lot nicer to work with classes.
> > 
> 
> Why not beginning to write the AST optimizer in C++?

I was under the impression it would be rejected (IE never be accepted in 
the maniline), so i never took it further.
> 
> The AST optimizer is not needed for building the C, nor the C++ compiler,
> but once g++ is built we could build the AST optimizer.

Sure, I knew this, but I still felt it wouldn't be accepted because of the 
associated stigma writing non-C seems to have in the GCC development 
world.
:)

Re: A FrontEnd in C++?

[Gabriel Dos Reis]

Michael Matz <matz@suse.de> writes:

| If it pops up, we can value if it really adds too much burden.

But, for that to happen such an initiative should -not- be discouraged :-)

-- Gaby

Re: A FrontEnd in C++?

[Phil Edwards]

On Wed, Aug 21, 2002 at 10:40:40AM -0700, Zack Weinberg wrote:
> like to remind him of the large number of "failure to bootstrap with
> Ada enabled" PRs currently sitting unaddressed in GNATS: 6016, 6160,
> 6552, 6573, 6584, 6661, 6669, 6696, 6767, 6816, 6851, 6852, 6853,
> 6872, 6879, 6931, 6942, 7209, and 7337.

*skims PRs*

Egads.

Now I don't feel so bad about giving up on getting Ada to work on my box.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: A FrontEnd in C++?

[Ross Smith]

On Thursday, 22 August 2002 05:40, Zack Weinberg wrote:
>
> 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.
>
> There is an intrinsic complexity burden to maintaining a program with
> components written in multiple languages.

But there is also an intrinsic complexity burden in trying to write very 
advanced software in a language as primitive and clunky as C. It's not 
at all clear to me that the added complexity caused by mixing source 
languages would outweigh the reduced complexity caused by using a more 
powerful language such as C++; in fact the reverse seems much more 
likely.

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

We already do. g++ and libstdc++ are perfectly good.

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

Since the C++ language includes a standard construct (extern "C") 
specifically for this purpose, I don't see this as an issue.

> I raised the Ada front end as an example, since it is the only front
> end written in its own language currently present in the official GCC
> tree.  I am certain that (for instance) a C++ front end written in
> C++ would have the same sorts of problems.

But nobody is talking about writing a C++ front end in C++, or for that 
matter about writing a Language X front end in Language X. This whole 
"bootstrap a front end in its own language" issue is a straw man you've 
introduced. The suggestion being discussed is writing a Language X (for 
X!=C && X!=C++) front end in C++ -- _specifically_ C++, not just any 
arbitrary language.

Any objections based on analogies to Ada are irrelevant, because (it 
seems from what those in the know have been saying here) most of the 
Ada front end's problems are consequences of bootstrapping in the same 
language, which isn't under consideration here.

-- 
Ross Smith ..................................... Auckland, New Zealand
r-smith@ihug.co.nz ...................................................

        "A specter is haunting Wall Street; it is the specter
        of honest accounting."           -- Arthur D. Hlavaty

Re: A FrontEnd in C++?

[Zack Weinberg]

On Thu, Aug 22, 2002 at 06:48:10AM +1200, Ross Smith wrote:
> On Thursday, 22 August 2002 05:40, Zack Weinberg wrote:
> > There is an intrinsic complexity burden to maintaining a program with
> > components written in multiple languages.
> 
> But there is also an intrinsic complexity burden in trying to write very 
> advanced software in a language as primitive and clunky as C. It's not 
> at all clear to me that the added complexity caused by mixing source 
> languages would outweigh the reduced complexity caused by using a more 
> powerful language such as C++; in fact the reverse seems much more 
> likely.

Sure.  This is why I'm not a priori opposed to rewriting the entire
compiler in a more powerful language.  C++ seems a logical choice; it
has fewer compatibility issues with C than other languages, and would
definitely provide benefits.  Simply being able to use STL for basic
data structures might be worth the change.

We would have to be prepared to require a relatively modern C++
compiler to bootstrap with, and given that we still require K+R
compatibility I don't see that happening anytime soon.

I *am* opposed to rewriting anything *less* than the entire compiler
in C++ or any other language, for previously stated reasons.

> > You have to have a functional compiler and runtime library for
> > each source language, for starters.
> 
> We already do. g++ and libstdc++ are perfectly good.

Not starting from scratch you don't have g++ and libstdc++.  Think
about bootstrapping.

[...]
> Any objections based on analogies to Ada are irrelevant, because (it 
> seems from what those in the know have been saying here) most of the 
> Ada front end's problems are consequences of bootstrapping in the same 
> language, which isn't under consideration here.

I do not agree with this assertion.  I believe that the Ada front
end's problems are largely due to being written in not-C, and the
fact that not-C happens to be Ada is irrelevant.

zw

Re: A FrontEnd in C++?

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

| > We already do. g++ and libstdc++ are perfectly good.
| 
| Not starting from scratch you don't have g++ and libstdc++.  Think
| about bootstrapping.

Certainly, but C++ used to have a front-end written in C++, called
CFront.  We all know how such a thing can be made.  I'm not convinced
that the additional work is higher than continuing to track and
implement things in C.  I'm not at all advocating for rewritting the
compiler in C++, but I'm not convinced that the supposed intrinsic
complexity makes the current situation any better. 

-- Gaby

Re: A FrontEnd in C++?

[Fergus Henderson]

On 21-Aug-2002, Zack Weinberg <zack@codesourcery.com> wrote:
> 
> 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.
> 
> There is an intrinsic complexity burden to maintaining a program with
> components written in multiple languages.  You have to have a
> functional compiler and runtime library for each source language, for
> starters.  On top of that, all the languages have to be ABI
> compatible;

That is an overstatement.  The "native" calling conventions used by each
of the different languages do not need to be ABI compatible.  All that is
needed is for the languages to have a way of interfacing with each other.
Most modern languages have a way of interfacing with C.

For example, C++ uses different name mangling than C, so C++ is not
"ABI compatible" with C, but you can use the extern "C" feature to
interface with C.

For another example, the Mercury compiler's original back-end generates
code which uses a completely different calling convention than C,
but you can use Mercury's C interface features to interface with C.

> historically, very little effort has been put into
> maintaining that compatibility (beyond what is needed to interface the
> language runtime to the system), so it is not a thing to be relied on.

My experience is that when using a language other than C, lots of attention
gets paid to the C interface.  People are forever building bindings to C
libraries, because there are so many useful C libraries out there.
In other words, the C interface gets tested quite well.
It can indeed be relied on.

> I am not a priori opposed to reworking the *entire compiler* in a
> different language,

Doing that wouldn't eliminate the dependencies on the language's C
interface.  The C interface will still be needed, either in the source
code for GCC or in the other language's standard library or runtime
system, in order to access OS facilities which are defined with a C API.

I think the benefits of writing in an appropriate higher-level language 
can far outweigh the minor drawbacks that you identify.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: A FrontEnd in C++?

[Gabriel Dos Reis]

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

Re: A FrontEnd in C++?

[Zack Weinberg]

On Thu, Aug 22, 2002 at 09:09:59PM +0200, Gabriel Dos Reis wrote:
> 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.

Please, everyone, join me in a thought experiment.  Imagine that you
are writing a compiler.  It doesn't matter what language(s) you are
writing in.  You're working under the following constraint: You must
assume that no other component of the system works as specified,
unless you have no choice.  Thus, you trust the operating system
kernel, since you have no choice there.  You just barely trust the
bootstrap compiler(s) to generate correct machine code, when no
optimization is enabled and no clever features of the language(s) are
used.  (Clever features include everything that doesn't have a trivial
translation to machine code.)  You do not trust the language(s)'
runtime librar(ies) to work at all.

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.)

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.

zw

Re: A FrontEnd in C++?

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

[...]

| 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.

I'm afraid I don't come to the same conclusions as you.  

That doesn't mean you're wrong nor am I.  I do have enought concrete,
working examples supporting my "other" approach to believe that it
works in pratice.  Very well :-).

[...]

| 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.

It just is *a* way.  There are other alternatives.

-- Gaby

Re: A FrontEnd in C++?

[Fergus Henderson]

On 22-Aug-2002, Zack Weinberg <zack@codesourcery.com> wrote:
> Please, everyone, join me in a thought experiment.  Imagine that you
> are writing a compiler.  It doesn't matter what language(s) you are
> writing in.  You're working under the following constraint: You must
> assume that no other component of the system works as specified,
> unless you have no choice.  Thus, you trust the operating system
> kernel, since you have no choice there.  You just barely trust the
> bootstrap compiler(s) to generate correct machine code, when no
> optimization is enabled and no clever features of the language(s) are
> used.  (Clever features include everything that doesn't have a trivial
> translation to machine code.)  You do not trust the language(s)'
> runtime librar(ies) to work at all.
> 
> 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.

No, I don't agree at all.

If you are working under those constraints, then rather than writing a
whole compiler in the untrusted bootstrap language (e.g. C), it would
be better to just write a simple bytecode interpreter in the untrusted
bootstrap language.  A bytecode interpreter is going to be simpler than a
compiler, so it is less likely to trigger bugs in the bootstrap compiler.

Then, you write your compiler with two back-ends, one that compiles
to this bytecode, and another that compiles to whatever it was that
you really wanted to compile to (e.g. native code).  The compiler
can be written in its own language, and bootstrapped using a trusted
implementation of that language (or by some other means, e.g. see Robert
Dewar's suggestions).

Then you ship the sources plus the compiled bytecode for the compiler.
When installing on untrusted systems, you first compile the bytecode
interpreter, and then use that to run the compiled bytecode for the
compiler, which you then use to compile your compiler to your chosen
target language (e.g. native code).

This approach
	(1) minimizes the amount of code which needs to depend on
	    the bootstrap compiler (only a bytecode interpreter)
	(2) allows you to use your language of choice for implementing
	    the compiler
and	(3) because of (2), reduces the overall complexity of the system
            compared to your suggested approach

One the down side, it requires adding an additional target language
(the bytecode), but that drawback is minor because the system will
already be designed to support multiple target languages, and the
additional target language is easy to compile to and doesn't need an
optimizing back-end.

> 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.

GCC already violates the constraint that "You must assume that no other
component of the system works as specified, unless you have no choice.",
since it depends on the bootstrap compiler being able to correctly
compile a whole C compiler, rather than just a bytecode interpreter.

(Indeed, if you only use the default three-stage bootstrap, then the
bootstrap compiler needs to correctly compile a whole *optimizing* C
compiler.  With the three-stage bootstrap process, the stage 1 compiler
is built without optimization, but the stage 2 compiler is built with
optimization enabled.  This depends on the bootstrap compiler having
correctly compiled the stage 1 optimizer.  Using a four-stage bootstrap
process, so that the stage 2 compiler is built without optimization, and
is then used to build a stage 3 compiler with optimization which is then
used to build a stage 4 compiler to check against the stage 3 compiler,
avoids this, thus reducing the dependencies on the correctness of the
bootstrap compiler.)

> 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.

Here again I disagree.  There's nothing wrong with using C++ or Java,
since GCC already includes C++ and Java compilers written in C.
Using C++ or Java would not increase the dependencies on the
correctness of the bootstrap compiler(s), because this C++ or Java
code can be compiled using the trusted stage 3 GCC rather than
relying on any C++ or Java compilers already installed on the system.
(Or equivalently, it can be compiled using the not-yet-trusted
stage 2 GCC, so long as part of the process includes checking
that the stage 2 GCC is bit-for-bit identical with the stage 3 GCC.)

Using Mercury to implement the Mercury front-end does not add a
dependency on another bootstrap compiler, since the Mercury compiler
can generate portable C code which you can ship.  Furthermore, it does
not even increase the dependencies on the correctness of the bootstrap
compiler(s), since the Mercury-generated C code can be compiled with
the trusted stage 3 GCC rather than with the untrusted bootstrap compiler.

Using Ada to implement the Ada front-end does increase the dependencies
on the correctness of the bootstrap compilers, since it requires a
correct Ada compiler to bootstrap with, not just a correct C compiler.
But that would not be the case for front-ends written in C++ or Java,
or for front-ends written in any language for which there is a compiler
to C, C++, or Java.  Nor would it be the case for front-ends written
in any language for which there is a compiler to a bytecode language
whose interpreter is written in C, C++, or Java.  (Actually, I should
also include Fortran in that list -- but who'd want to write compilers
or interpreters in Fortran? ;-)

Even though writing the Ada front-end in Ada increases the dependencies
on bootstrap compilers, this drawback is IMHO *far* outweighed by the
benefits of writing the compiler in the same language.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: A FrontEnd in C++?

[Toon Moene]

Fergus Henderson wrote:

> (Actually, I should

Re: A FrontEnd in C++?

[Kai Henningsen]

fjh@cs.mu.OZ.AU (Fergus Henderson)  wrote on 23.08.02 in < 20020823092008.GA2439@ceres.cs.mu.oz.au >:

> If you are working under those constraints, then rather than writing a
> whole compiler in the untrusted bootstrap language (e.g. C), it would
> be better to just write a simple bytecode interpreter in the untrusted
> bootstrap language.  A bytecode interpreter is going to be simpler than a
> compiler, so it is less likely to trigger bugs in the bootstrap compiler.
>
> Then, you write your compiler with two back-ends, one that compiles
> to this bytecode, and another that compiles to whatever it was that
> you really wanted to compile to (e.g. native code).  The compiler
> can be written in its own language, and bootstrapped using a trusted
> implementation of that language (or by some other means, e.g. see Robert
> Dewar's suggestions).
>
> Then you ship the sources plus the compiled bytecode for the compiler.
> When installing on untrusted systems, you first compile the bytecode
> interpreter, and then use that to run the compiled bytecode for the
> compiler, which you then use to compile your compiler to your chosen
> target language (e.g. native code).

I seem to remember suggesting something along those lines in one of the  
bootstrap-Ada debates, except I suggested using one of the existing  
emulators iff one was suitably portable.

It would also enable using full C99 in the C part of gcc, as the  
requirement to compile with the host compiler vanishes.

Note also that you do not necessarily need to regenerate the bytecode  
version of the compiler every time, only when you find that it doesn't do  
something (or does it wrong) that you need to have to bootstrap gcc.

MfG Kai

Re: A FrontEnd in C++?

[Alexandre Oliva]

On Aug 19, 2002, Zack Weinberg <zack@codesourcery.com> 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.

I disagree.  The problems have all been caused by the front end
requiring a pre-existing, compatible build of itself to build.  Using
C++ to create a front end for any language other than C++ wouldn't
bring in any new problems.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: A FrontEnd in C++?

[Michael S. Zick]

On Monday 19 August 2002 08:55 am, Alexandre Oliva wrote:
> On Aug 19, 2002, Zack Weinberg <zack@codesourcery.com> 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.
>
> I disagree.  The problems have all been caused by the front end
> requiring a pre-existing, compatible build of itself to build.  Using
> C++ to create a front end for any language other than C++ wouldn't
> bring in any new problems.

I have to agree with Alexandre.
And this has a lot of bearing on the recent hot thread: "Faster compilation 
speed".

Based on current Makefile usage...
Referring to a 3-stage build as stage0, stage1, stage2 with stage0 currently 
unlabeled...

The (intended) purpose of the stage0 phase is to build a "build compatible" 
compiler from whatever is at hand.
Historically: "any 'ol C compiler"
Recently, this has been expanded "any 'ol C compiler" plus "any 'ol Ada 
compiler" (if they are link compatible or stage0 binutils can be built to 
make them so).

During my "pre-thinking" of revising the makefiles...
I don't see any reason (from the stand point of the makefiles, that is) why 
this can't be generalized to: "any 'ol collection of compilers for any 'ol 
collection of languages"

How does this apply to speeding up the compiler? - Qood question, I'm getting 
there...

Suppose the folks doing all of the work on optimizing code, optimizing 
register usage, etc; come to an agreement such as:
"Doing all of this in C is giving us:
1) poor spacial (sp?) locality for the code, it needs to be better.
2) the spacial locality of the data really sucks
let us rewrite these parts in lanuage xyz".

lisp? elist? RTL_the_language? whatever... don't get focused on any one name 
for now...

Consider for now, any of the many languages which can be implemented as an 
"extensible, threaded, interpertive" language. (I am talking late 1970's 
technology here.)

Functionally, the implemenation would:
1) translate source code -> bytecode (such as "precompile elisp")
2) on receipt of specific command code: 
    2a) traverse a function's byte code, optimize out (I.E: inline) all of 
the calls to its predcessor functions -> one bigger chunk of byte code.
    2b) do a few, simple "peephole" optimizations.
    2c) rather than interpret this now bigger, optimized chunk of byte code; 
use the byte code interpreter's look-up table to look-up the corresponding, 
native, binary, function calls (all of which are written PIC) - strip the 
pre-amble, post-amble, copy the remaining instructions somewhere - call it an 
object code library if you like.

You don't have to spend a lot of time making the above a real "killer 
language app" - it's lifetime will be very short.

I haven't totally lost my mind here - I did several of these about twenty 
years ago - it isn't any bigger a challange than you let it become.

What does that achive?
Considering how the binary was generated, you have done spacial (sp?) 
locality compression.  I.E: by coaxing the conversion process a little, you 
can force I-cache line(s) sizes of instruction chunks.

Now comes the speculation part, which I didn't do in those old TIL's...

Bytecode the data references the TIL language uses.
Follow the same translate, combine, simplifiy, convert.  Converting to 
"native", "packed" data structures.  I.E: eleminate as much "pointer chasing" 
as possible.

So that does spacial (sp?) locality compression for the data.  Here, again, 
with a little coaxing, build D-cache line(s) sizes of data structure chunks.

Now the bootstrap process becomes (adding a "partial" stage):

stage0a: 
generate a "build compatible", approximation of GCC using "any 'ol C 
compiler" and the existing trees, in-liners, etc. plus the source (in C) of 
the "self compiling" approximation of the language the new trees, in-liners, 
optimizers are written in.

stage0b: 
toss the existing sources for trees, in-liners, etc; substituting the sources 
(in the new, whatever, language) for the new replacements.  Generating a 
"fully compiled", GCC-C compatible, New Optimizer compatible; "build 
compiler".

stage-next: Build GCC with the user specified options, features, and 
languages.

Continue per existing build process.

See - that bytecode thing didn't live very long (minutes, probably).

Such a process would allow even the "internals" of the GCC-C compiler be 
built from multiple languages.  I think it may be the direction to take in 
speeding up the compiler.

Mike

Re: A FrontEnd in C++?

[Diego Novillo]

On Mon, 2002-08-19 at 04:02, Zack Weinberg 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.
> 
I disagree.  If anything, I would encourage languages *other* than C for
writing front ends.  Use the right language for the problem at hand.

C is such a barbaric language for writing compilers.  Too bad we have to
cater to the lowest common denominator.


Diego.

Re: A FrontEnd in C++?

[Mike Stump]

On Monday, August 19, 2002, at 01:02 AM, Zack Weinberg wrote:

Re: A FrontEnd in C++?

[Florian Weimer]

Zack Weinberg <zack@codesourcery.com> writes:

> 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.

Most of the problems with Ada frontend are due to self-hosting, and
not due to using another language instead of C.

Re: A FrontEnd in C++?

[Matt Austern]

On Monday, August 19, 2002, at 12:46 AM, Fergus Henderson wrote:

Re: A FrontEnd in C++?

[Kelley Cook]

Michael S. Zick wrote:
>Writing a front end in C++ would make that process:
>
>Stage0: any 'ol C compiler -> gcc<c, c++>
>Stage1: gcc<c, c++> + new_frontend -> gcc<c, c++, New>
>Stage2: gcc<c, c++, New> -> presumably_finished_compiler
>Stage3: presumably_finished_compiler -> finished_compiler
>
>Compare Stage2 with Stage3, if same; then done; else punt!

Why?

You just need to treat the new front end the same as, say, the C++ Standard
Library, which requires C++ to build.

So you really get the exact same as what we have now.

Unamed Stage0: any 'ol C compiler -> gcc<c>
Stage1: gcc<c> -> presumably_finished_compiler <c, c++, F77, Java>
Stage2: presumably_finished_compiler -> finished_compiler <c, c++, F77, Java>

Compare stage1 and stage2

If they compare, then do the unnamed stage3 which is to build Fortran's, C++'s,
and Java's Libraries as well as your new Frontend that was written in C++.

Of course, I don't see that there is a good reason other than "It's always been
done that way" and for a greater code sample for the compare to build C++, F77,
and Java in stage 1.  But that is not for this discussion.

Kelley Cook

Re: A FrontEnd in C++?

[Kevin Handy]

Kelley Cook wrote:

Re: A FrontEnd in C++?

[khalid aggag]

Writing a front end in C++ would make that process:

Stage0: any 'ol C compiler -> gcc<c, c++>
Stage1: gcc<c, c++> + new_frontend -> gcc<c, c++, New>
Stage2: gcc<c, c++, New> -> presumably_finished_compiler
Stage3: presumably_finished_compiler -> finished_compiler

Re: A FrontEnd in C++?

[Michael S. Zick]

On Sunday 18 August 2002 04:36 pm, khalid aggag wrote:
> >>Writing a front end in C++ would make that process:
> >>
> >>Stage0: any 'ol C compiler -> gcc<c, c++>
> >>Stage1: gcc<c, c++> + new_frontend -> gcc<c, c++, New>
> >>Stage2: gcc<c, c++, New> -> presumably_finished_compiler
> >>Stage3: presumably_finished_compiler -> finished_compiler
> >>
> >>Compare Stage2 with Stage3, if same; then done; else punt!
>
> Isnt this possible by having a C++ compiler already installed on the system
> and enabling the C++ as a langauge to be built?
>
> Khalid Aggag
>
I guess you mean:

Stage0: any 'ol C++ compiler + new_frontend -> gcc<c, c++, New>
Stage1: gcc<c, c++, New> -> presumably_finished_compiler
Stage2: presumably_finished_compiler -> finished_compiler

Returning to the "standard method" of a three stage bootstrap.
But note:
1) The current "Makefiles" can handle a 4-stage bootstrap 
2) Your proposal would require a POLICY CHANGE from the historical method of 
bootstrapping GCC.

Making any required changes to the "Makefiles" (no pun intended) would 
probably be much more acceptable than changing a long standing policy.  A 
policy made and still kept for very good reasons.

Please note: I am only modifing the "install directions" - anything outside 
of the file: "install.texi" is somebody else's area.

Mike

Re: A FrontEnd in C++?

[Per Bothner]

khalid aggag wrote:

Re: A FrontEnd in C++?

[Robert Dewar]

<<> 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.
>>

I really don't see any major problems with Ada being written in Ada, we have
never had trouble building, and lots of people have built GNAT V5 from the
gcc sources successfully.

>>C is such a barbaric language for writing compilers

I have to agree with this. You really really need a language that supports
abstraction well for writing compilers.

Re: A FrontEnd in C++?

[Robert Dewar]

What zw discounts in his argument is the huge gain in writing a compiler in
a high level language with good abstraction facilities. There are also
other huge advantages of writing a compiler in its own language:

Avoiding a culture clash. For example, COBOL compilers should be written by
people who really know COBOL well. Such people are not likely to be happy
writing in C. I know of more than one COBOL compiler written in C by
C programmers who really disliked COBOL, and it shows!

Having one really complex test program that must function really well before
you can even get out of the starting gate is a real advantage.

You have more incentive to improve the compiler, since improvements help compile
speed as well as generally assisting users.

A compiler is one component in development systems now, and the quality of
integrated tool sets is critical. If you write a compiler in its own language
then your development team uses the tools that surround the compiler that support
this language, and they have an incentive to develop and improve these tools.

If you run into troubles with the compiler compiling your compiler, you do not
have to rely on external support to solve them. You are the maintainer from whom
you need your own help. Since you know the urgency of your own needs, you will
get excellent support.

As for problems with mixed languages, we have found that to be very little
trouble in practice on a wide range of machines, and many people have succeeded
in building modified compilers (it is in fact an assignment I have given to
many students: "make some interesting modification to GNAT" :-)

A lot of the growing pains in integrating Ada into the FSF structure come from
the fact that this is the first time it is done, so we have had to learn how
it should be done, and from people having the unrealistic expectation that 
you should be able to build from any old ancient version of GNAT used together
with some unrelated version of C.

I think once we have gone through a couple of release cycles with GNAT there,
the problems will mostly take care of themselves.

Re: A FrontEnd in C++?

[Geoff Keating]

dewar@gnat.com (Robert Dewar) writes:

> A lot of the growing pains in integrating Ada into the FSF structure
> come from the fact that this is the first time it is done, so we
> have had to learn how it should be done, and from people having the
> unrealistic expectation that you should be able to build from any
> old ancient version of GNAT used together with some unrelated
> version of C.
> 
> I think once we have gone through a couple of release cycles with
> GNAT there, the problems will mostly take care of themselves.

The problems I found with building Ada are all related to trying to
obtain a version of GNAT to use to bootstrap.  There are two ways you
can do this:

1. Take an old version of GNAT, and try to use that.  This doesn't
   work, because you need a _current_ version.  The rest of GCC does
   not need a current version of GCC to bootstrap itself; any working
   C compiler will do, and we stretch the definition of "working" to
   include (for instance) the base compiler on IRIX.  By comparison,
   GNAT requires not just any working Ada compiler, but GNAT, and not
   any GNAT, but one of a small set of versions.

2. Build a cross-compiler from a system that does have a suitable
   version of GNAT.  This doesn't work because of various bugs in GNAT
   and in building cross-compilers.  These bugs wouldn't matter so
   much if GNAT wasn't built, because it's rare that anyone needs a
   cross-compiler from, say, linux to AIX (see PR 6872), unless they
   want GNAT.  It doesn't help that GNAT's build process with cross
   compilers is much less user friendly than (and different to) the
   rest of GCC (see PRs 5910, 5911).

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: A FrontEnd in C++?

[Robert Dewar]

> Now I don't feel so bad about giving up on getting Ada to work on my box.

In fact lots of people have succeeded. The critical factor is to get a reasonably
late distribution of GNAT, and use the Ada compiler you get to build the Ada part
and the C compiler that comes with it to build the C part, and it will work fine.
That's not just theory, that's what is reported back to us from lots of Ada folks.

Re: A FrontEnd in C++?

[Graham Stott]

Robert Dewar wrote:

Re: A FrontEnd in C++?

[Zack Weinberg]

On Wed, Aug 21, 2002 at 02:53:19PM -0400, Robert Dewar wrote:
> > Now I don't feel so bad about giving up on getting Ada to work on my box.
> 
> In fact lots of people have succeeded. The critical factor is to get
> a reasonably late distribution of GNAT, and use the Ada compiler you
> get to build the Ada part and the C compiler that comes with it to
> build the C part, and it will work fine.  That's not just theory,
> that's what is reported back to us from lots of Ada folks.

For the second time: GNATS PRs 6016, 6160, 6552, 6573, 6584, 6661,
6669, 6696, 6767, 6816, 6851, 6852, 6853, 6872, 6879, 6931, 6942,
7209, and 7337.

Now I did just succeed in building the GCC 3.3 source tree with Ada
enabled (incl make gnatlib_and_tools), using C and Ada compilers from
GCC 3.2.  It is possible that some or all of these PRs have been
fixed.  However, the impression one gets flipping through GNATS is
that they have all been ignored.

zw

Re: A FrontEnd in C++?

[Robert Dewar]

> No.  The intrinsic complexity burden I am talking about is exclusively
> a function of the number of different languages used in the source
> tree (ignoring runtime libraries).  It doesn't matter which bits are
> written in which languages.

Mixed languages are reality in large applications these days. We deal with people
writing large (much much larger than gcc) applications in mixed languages
typically Ada C C++ and one of the great strengths of gcc is that it handles
this situation very smoothly. 

Re: A FrontEnd in C++?

[Richard Kenner]

    For the second time: GNATS PRs 6016, 6160, 6552, 6573, 6584, 6661,
    6669, 6696, 6767, 6816, 6851, 6852, 6853, 6872, 6879, 6931, 6942,
    7209, and 7337.

    Now I did just succeed in building the GCC 3.3 source tree with Ada
    enabled (incl make gnatlib_and_tools), using C and Ada compilers from
    GCC 3.2.  It is possible that some or all of these PRs have been
    fixed.

All of these were due to using a non-working version of GNAT as the bootstrap
source, as far as I know.  Nobody who has started from a working version
has had a problem.

Re: A FrontEnd in C++?

[Zack Weinberg]

On Wed, Aug 21, 2002 at 07:19:11PM -0400, Richard Kenner wrote:
>     For the second time: GNATS PRs 6016, 6160, 6552, 6573, 6584, 6661,
>     6669, 6696, 6767, 6816, 6851, 6852, 6853, 6872, 6879, 6931, 6942,
>     7209, and 7337.
> 
>     Now I did just succeed in building the GCC 3.3 source tree with Ada
>     enabled (incl make gnatlib_and_tools), using C and Ada compilers from
>     GCC 3.2.  It is possible that some or all of these PRs have been
>     fixed.
> 
> All of these were due to using a non-working version of GNAT as the bootstrap
> source, as far as I know.  Nobody who has started from a working version
> has had a problem.

In that case, it would be courteous to take ten minutes, annotate all
these bug reports with a request to try again with a "working version"
(however you define that this month) and set them all to feedback
state.

zw

RE: A FrontEnd in C++?

[Billinghurst, David (CRTS)]

This is not the case for PR 6942.

I built a working Ada compiler with 3.2, but the bootstrap now fails 
with 3.3.  I even identified the patch that broke it.

-----Original Message-----
From: Richard Kenner [ mailto:kenner@vlsi1.ultra.nyu.edu ]
Sent: Thursday, 22 August 2002 9:19 
To: zack@codesourcery.com
Cc: gcc@gcc.gnu.org
Subject: Re: A FrontEnd in C++?


    For the second time: GNATS PRs 6016, 6160, 6552, 6573, 6584, 6661,
    6669, 6696, 6767, 6816, 6851, 6852, 6853, 6872, 6879, 6931, 6942,
    7209, and 7337.

    Now I did just succeed in building the GCC 3.3 source tree with Ada
    enabled (incl make gnatlib_and_tools), using C and Ada compilers from
    GCC 3.2.  It is possible that some or all of these PRs have been
    fixed.

All of these were due to using a non-working version of GNAT as the bootstrap
source, as far as I know.  Nobody who has started from a working version
has had a problem.

Re: A FrontEnd in C++?

[Robert Dewar]

<<Now I did just succeed in building the GCC 3.3 source tree with Ada
enabled (incl make gnatlib_and_tools), using C and Ada compilers from
GCC 3.2.  It is possible that some or all of these PRs have been
fixed.  However, the impression one gets flipping through GNATS is
that they have all been ignored.
>>

Indeed I do not know of anyone who is looking at this particular set of
GNATS PRs. For us getting GNAT to work reliably with GCC 3 is far higher
priority, and we get mostly very positive input from people regarding the
build process, so that has not seemed a critical priority.

Re: A FrontEnd in C++?

[Robert Dewar]

<<All of these were due to using a non-working version of GNAT as the bootstrap
source, as far as I know.  Nobody who has started from a working version
has had a problem.
>>

That's my impression also.

RE: A FrontEnd in C++?

[Richard Kenner]

    This is not the case for PR 6942.

That PR clearly shouldn't have been in the list, since it has nothing
whatsoever to do with what language the compiler was written in.  It
is not a bug in Ada, but in language-independent CFG processing.  I
suspect the reason nobody has worked on it is that it's mis-characterized:
it has nothing to do with Ada except that that's what the test program
happens to be written in.

Re: A FrontEnd in C++?

[Robert Dewar]

> historically, very little effort has been put into
> maintaining that compatibility (beyond what is needed to interface the
> language runtime to the system), so it is not a thing to be relied on.

While this statement is absolutely true about C, which has never had any
facilities for interfacing with other languages, it takes only one to tango
here, and other languages *do* concern themselves with multi-language
programming. For example in Ada a required feature is

   pragma Import (C, name-of-function-in-Ada, name-of-function-in-C);

and the compiler is *required* to make sure that the calling sequence is
C-compatible.

Actually in the case of GNAT, we don't even need to use pragma Import, since
the default calling convention is precisely compatible with C anyway.

Re: A FrontEnd in C++?

[Chris Lattner]

> Go right ahead.  All you need is a new branch and some free time.  I
> would personally suggest following some of the design and implementation
> ideas from SUIF and/or Sage++.  They are kind of neat.

As long as we are plugging compiler infrastructures, I thought I might
mention my own project LLVM: http://llvm.cs.uiuc.edu/

It's also completely written in C++ (G++ 3.2), uses a GCC->LLVM frontend,
is SSA based, open-source, and has some interesting technology available
in it.  The LLVM instruction set is roughly equivalent to SIMPLE
( http://llvm.cs.uiuc.edu/docs/LangRef.html ).

A few of the nify things LLVM provides are the modular pass system:
http://llvm.cs.uiuc.edu/docs/WritingAnLLVMPass.html
strong infrastructure for interprocedural optimizations, linktime, and
runtime optimizations, etc.  The infrastructure is _very_ fast.

Additionally, because it uses C++ and the STL throughout, writing
transformations is quite simple.  For example, LICM and GCSE are each
just a couple hundred lines of code (which are mostly comments):

http://llvm/doxygen/LICM_8cpp-source.html
http://llvm/doxygen/GCSE_8cpp-source.html

If you have any questions about LLVM or would like to discuss compiler
architecture, I'd be more than happy to participate.

-Chris

Re: A FrontEnd in C++?

[Robert Dewar]

> 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.

Re: A FrontEnd in C++?

[Geoff Keating]

dewar@gnat.com (Robert Dewar) writes:

> 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.

You do admit, though, that ACT is not the typical case for GNAT?  Most
builders of GNAT are not the developers and do not have access to the
hardware, software, or expertise that ACT does.  If we only cared
about ACT building the compiler it would be unnecessary to have it in
the FSF CVS repository at all.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: A FrontEnd in C++?

[Hans-Peter Nilsson]

On Thu, 22 Aug 2002, Robert Dewar wrote:
> 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,

With no bugs exposed in the GCC MMIX port?  Strange.  1/2 :-)

brgds, H-P

Re: A FrontEnd in C++?

[Robert Dewar]

>>With no bugs exposed in the GCC MMIX port?  Strange.  1/2 :-)

Sorry, you misread what I said, this assignment had nothing whatsoever
to do with the GCC MMIX port. The students wrote complete compilers that
parsed Algol-68 source, semantically analyzed the resulting trees, and 
then generated optimized (more or less, some optimized more than others :-)
assembly language for MMIX.

Re: A FrontEnd in C++?

[Robert Dewar]

>>You do admit, though, that ACT is not the typical case for GNAT?

Well there are lots of people who have not only completed the build
and cross port (the easy part), but have also ported the entire toolset
and run time library (I am talking about people outside ACT here).

Several GNAT ports were done entirely outside ACT's sphere.