Compiler for gcc

[Harshal Jain]

As we all know gcc is used to compile c programming codes n also to
compile linux kernel
bt i wanted 2 know in which programming language compiler for gcc is
written??
plz rly me on (e-mail address removed)

 

[Tom St Denis]

Traditionally compilers compile themselves.
This chicken and egg situation can be resolved in serveral ways, eg a cross
compiler, or an initial run through an interpreter build specially for the
purpose.

From the dragon book apparently one of the first pascal compilers was
compiled by hand, then after that compiled itself.

Without digging around I'd guess GCC started with another C compiler
bootstrapping the process. I know that's how DJGPP started, it was
built on another platform that compiled to make MS-DOS executables.

Tom

 

[robertwessel2]

Traditionally compilers compile themselves.
This chicken and egg situation can be resolved in serveral ways, eg a cross
compiler, or an initial run through an interpreter build specially for the
purpose.

While that's reasonably common (although far from universal, or even
true for the majority of implementation) with C, C++, and a few other
high level languages, the vast majority of compilers in existence do
not, and cannot, compile themselves. Consider, for example, any of
the 50 or so C (or C-like) compilers for the 8051 - likely none of
those would be up to compiling a whole C compiler. Or the vast number
of compiled small languages. Or consider that many C++ compilers are
written in C++, and most (all?) of those are also C compilers, which
are then implicitly also written in C++. Or just look at the
different languages in the GCC.

Compilers should be written in a language that's convenient for
writing a compiler. For some definition of "convenient" - two obvious
definitions are a language good at manipulating data structures like
you commonly find in a compiler (which might suggest a language like
Haskell), or a language commonly available on the target platforms
(which would suggest something like C). The language a compiler
compiles is fairly orthogonal to that.

The compiler bootstrapping thing seems to be more an intro-to-CS gee-
whiz concept, which should be mostly ignored in practice.

Which is not to say that all sorts of languages haven't been used to
write compilers. I know of examples of Cobol, Fortran and Basic
compilers that *are* self hosted. Although none of those three
languages would be my first choice for writing a compiler. And I know
of Cobol and Basic compilers written in assembler and C too. I also
know of Ada implementations in Ada (which is no less reasonable a
language for a compiler than C), and in C.

 

[bartc]

The compiler bootstrapping thing seems to be more an intro-to-CS gee-
whiz concept, which should be mostly ignored in practice.

All the compilers I've worked on (on and off since 1979) have been written
in their own languages. Although one or two may have started off in
assembler. So that advice is a bit late for me.

(What I haven't yet managed is to write an interpreter in the same language
as is being interpreted, ie. to completely bootstrap it.)

Which is not to say that all sorts of languages haven't been used to
write compilers. I know of examples of Cobol, Fortran and Basic
compilers that *are* self hosted. Although none of those three
languages would be my first choice for writing a compiler.

Which language would be your first choice?

 

[BGB / cr88192]

Traditionally compilers compile themselves.
This chicken and egg situation can be resolved in serveral ways, eg a
cross
compiler, or an initial run through an interpreter build specially for the
purpose.

<--
While that's reasonably common (although far from universal, or even
true for the majority of implementation) with C, C++, and a few other
high level languages, the vast majority of compilers in existence do
not, and cannot, compile themselves. Consider, for example, any of
the 50 or so C (or C-like) compilers for the 8051 - likely none of
those would be up to compiling a whole C compiler. Or the vast number
of compiled small languages. Or consider that many C++ compilers are
written in C++, and most (all?) of those are also C compilers, which
are then implicitly also written in C++. Or just look at the
different languages in the GCC.

Compilers should be written in a language that's convenient for
writing a compiler. For some definition of "convenient" - two obvious
definitions are a language good at manipulating data structures like
you commonly find in a compiler (which might suggest a language like
Haskell), or a language commonly available on the target platforms
(which would suggest something like C). The language a compiler
compiles is fairly orthogonal to that.

The compiler bootstrapping thing seems to be more an intro-to-CS gee-
whiz concept, which should be mostly ignored in practice.

Which is not to say that all sorts of languages haven't been used to
write compilers. I know of examples of Cobol, Fortran and Basic
compilers that *are* self hosted. Although none of those three
languages would be my first choice for writing a compiler. And I know
of Cobol and Basic compilers written in assembler and C too. I also
know of Ada implementations in Ada (which is no less reasonable a
language for a compiler than C), and in C.

-->

yep...


sadly, not even my compiler, which compiles C (and is written in C), can
compile itself...

partly, it is because it focuses instead on JIT...
partly, it is because the thing is so damn buggy, that I have yet to even
make it work very well for even writing scripts... (it is more sort of "hit
or miss" whether or not the code actually compiles and works...).

more of an "oh, wow, cool", followed by a "this compiler doesn't really
actually work" experience...

at least... now the compiler doesn't tend to crash the app which tries to
use it, but I am faced with buggy output...

however, at least most of the "superstructure" is working "good enough" (the
system is not just a compiler, but a big mass of surrounding machinery as
well, comprising what is essentially a VM framework of sorts...).

this superstructure competes in terms of "usefulness" with the compiler
itself, where it is basically an ad-hoc collection of utility code, and
special purpose automatic code generation (which to a large extent give C
"reflection" abilities...). it differs from the compiler in that, it does
not have a centralized code generator, rather just lots of functions for
generating code for doing various tasks.

the reason for the split (a centralized codegen + a bunch of decentralized
code generation), is that it allows simplifying the core compiler (it does
not have to worry as much about the details of the runtime or the object
system, since a lot of this code will be generated automatically by the
runtime, allowing specific subsystems to generate those parts of code
relating to themselves...).

this allows the core codegen to be more generic as well, provided the
runtime provides the needed utilities (typically interfaced with via the
linker).


granted, I am now using the compiler on a different architecture (Win64 /
x86-64) than I originally wrote it to work with (Win32 / x86), which may be
part of at least some of the problems (a great big bug shakeout...).

now, what compiler do I use to compile it all (at present):
MSVC...


or such...

 

[robertwessel2]

All the compilers I've worked on (on and off since 1979) have been written
in their own languages. Although one or two may have started off in
assembler. So that advice is a bit late for me.

You've spent most of your time working on compilers for larger
languages than I, and most others, have. That's neither here nor
there, but my point is still that the vast majority of compilers don't
self-host, and most couldn't even if their authors wanted them to.

Which language would be your first choice?

It depends on the constraints of the projects. I actually *have*
written a compiler in Cobol (more than one, in fact), for a small
language, the output was assembler code, and the choice was driven by
the platform (C compilers were rare on mainframes in the eighties, and
there were, in fact, Cobol compilers available for the PC, which was
another planned target). As they say, necessity is a mother.

If my main job was to get a functional compiler up and running, on a
heavyweight and common development platform (IOW, *nix or Windows):
Scheme or Haskell.

If I need to produce a compiler that will likely have to distributed
to real world platforms, and need to fit in with a real world project
(particularly if its a small language compiler), it's most likely
going to be C++. C would have been a choice not that long ago, but I
really can't think of any platform that's likely to host a compiler
these days that doesn't have a C++ compiler available.

My preference is to emit assembler code. The final conversion to
object code is tedious and uninteresting, really, but I've done it
(and I actually have a limited x86 assembler in my toolkit, which I
can paste in if I want that).

Specific targets might open more options. If I was targeting Windows
specifically, C# is not a bad language, although you end up pretty
darn tied to the platform (Mono notwithstanding), and the whims of the
language vendor. Not something I've actually done, though.

As a general rule, I'd prefer a fairly type safe language for writing
a compiler, and probably a garbage collected one, since there's darn
little of that kind of low-level manipulation that a compiler actually
needs to do. And if a practical option like that presents itself, I
certainly don't mind learning a new language.

But the majority has been done in C or C++, and given the constraints
of the real world, I'm seeing a lot of C++ in the future...

 

[robertwessel2]

Specific targets might open more options.  If I was targeting Windows
specifically, C# is not a bad language, although you end up pretty
darn tied to the platform (Mono notwithstanding), and the whims of the
language vendor.  Not something I've actually done, though.

Java is right in the same ballpark as C# as a language, and it
certainly has more implementations. Although I seem to keep missing
ever doing any serious work in Java…

 

[Walter Banks]

The compiler bootstrapping thing seems to be more an intro-to-CS gee-
whiz concept, which should be mostly ignored in practice.

Most of the old computers developed tools and porting existing tools was a nightmare. The implementation language was assembler and memory was so expensive and rare that overlay linking was the norm.

It took until the early days of personal computers before cross compilers that ran on one machine generating code for another became common. Some of the smallc's and tiny c's probably can be compiled to run on embedded processors.

Our compilers have been moved from platform to platform but never compiled on the same processor as the target.

Completely bootstrapping a new processor is a lost art that I suggest is better not re-learning.

Anyone remember STAGE2?


Regards,

Walter..

 

[robertwessel2]

It took until the early days of personal computers before cross compilers that ran on one machine generating code for another became common. Some of the smallc's and tiny c's probably can be compiled to run on embedded processors.

Well, they certainly were common long before that. In fact you
couldn't program any of the early microprocessors (except in binary)
without at least a cross-assembler. Of course back then they
typically ran on minis.

One of the reasons Intel had so many design wins for their early CPUs
was that had decent development tools available.

 

[Walter Banks]

Well, they certainly were common long before that. In fact you
couldn't program any of the early microprocessors (except in binary)
without at least a cross-assembler. Of course back then they
typically ran on minis.

I think SmallC was written about 76 it was quite early a year or so after Pitman's Tiny Basic

One of the reasons Intel had so many design wins for their early CPUs
was that had decent development tools available.

True, they had good cross assemblers. They also had solid silicon and support

The first personal computer I built was mostly programmed with a cross assembler written in macros for Macro11 on a PDP-11. Our early consulting work was done the same way on a PDP-11 I bought from a bankruptcy. Later about 1980 we wrote cross assemblers
(a total of about 90 in ten years) in UCSD Pascal that ran on the PDP-11 later apples and IBM-PC's a some point re-implemented in Borland Delphi.;

Regards,


Walter..

 

[robertwessel2]

The first personal computer I built was mostly programmed with a cross assembler written in macros for Macro11 on a PDP-11.  Our early consulting work was done the same way on a PDP-11 I bought from a bankruptcy. Later about 1980 we wrote cross assemblers
(a total of about 90 in ten years) in UCSD Pascal that ran on the PDP-11 later apples and IBM-PC's a some point re-implemented in Borland Delphi.;

I'm pretty sure I remember you guys from the assembler era. Sorry -
we ended up using Avocet's products when we needed something like
that, although that wasn't always a happy experience... Of course the
same was true of much development software back then (today too, of
course, but, not to the extent it was back then).