Re: Extending Gcc For a New Language

[Mike Stump <mrs at apple dot com>]

Since you asked for more details...

On Wednesday, March 5, 2003, at 04:49 PM, Kevin Atkinson wrote:
> For my Ph D I am seriously considering designing a new System Program
> language.  Unlike many other new languages, my new language will be
> designed to be suitable for low-level programming tasks such as written
> kernels and operating systems, It is designed to replace C and C++
> (wishful thinking I know).

Since you experience the world through the eyes of C and C++, 
everything you see is colored in a certain way that prevents you from 
really wondering.  It is this type of wondering that will cause the 
most pain in adapting gcc.

> For the implementation I am considering two choices
>
> 1) Writing the compiler in its own language that emits C (or perhaps
> C++) code and then uses gcc to compile it.

This would be a good strategy for you; not because it is best, but 
because you then don't have to learn anything about gcc, the interface 
is very stable, and it should be expressive enough.  Though, you've not 
included enough details to say for sure.  Example, write a compile that 
compiles the language:

START: 'a'

where 'a' has the semantics of Hello, World.  Solution for C target:

int main() { if (getchar() != 'a') printf("parse error\n"); else 
printf("int main() { printf(\"Hello World\\n\");\n"); }

Solution for gcc target:

[ 5,096 line solution omitted for brevity ]

> 2) Extending Gcc to support the new language.

This is a better choice, but may involve more hair pulling.  The 
advantages are that you will be not as limited in what you can do with 
C, more flexibility to do odd things.  Ability to extend the gcc 
backend/midend to cover interesting new semantics you might need. 
Example, write code to do EH frame management when reverse inlining 
across translation units.   In hand rolled  C code, it can get tricky, 
inside gcc, you get it for free.  If you target C++, sure, it become 
easier, but only if you can map ontop of the C++ model directly, that 
might not be easy in some cases.  For example, there are some 
tranlation systems that emit the entire program as int main() { ... } 
so that they can do odd things that they could not do if they tried to 
spill into functions, and yet other just do foo1() { } foo2() { }...

> Because my language will offer features not currently supported by C or
> C++ (and probably Java, Ada, and Fortune but I don't know enough about
> those languages to be sure), it will me more than simply writing a new
> front end.

You need to take a high speed pass through the gcc internals manual, 
read the part on RTL, and see if what you want to do maps onto it.  If 
it does, your pretty well set and your frontend may be just a simple 
frontend.  There might be newer stuff with trees that would be more 
appropriate, but I am not as familiar with those parts of the manual.  
In addition, you can skim tree.def and the functional interfaces of 
files like function.c/expr.c/tree.c to get a feel for that gcc can do 
for you.

Newer features doesn't cause a mapping failure by itself.  To cause a 
mapping failure, you have to want to do something fundamentally 
different.  For example, collapsing like code across translation units 
is a _new_ feature in gcc.  It used to not be there.  We had to add it 
for C++.  Because we did, anybody can now use it to solve a wide range 
of problems. Need a lock object across translation units that is 
shared, but you're unsure were to allocate it and you want it allocated 
statically?  No problem.

Want to transfer control through the call stack based upon runtime 
decisions to some arbitrary point in the past stack (trying to describe 
EH), no problem.

>   Some of the features the language may offer:
>
> * Type inference in the style of most functional programming 
> languages, but
> perhaps a bit more limited.  Generally global variables and function
> parameters will have the types specified, but the compiler will be
> expected to infer the types for local variables.

cp/pt.c  It is a purely frontend issue.  You can write what ever 
arbitrary code you want.
Would be nice to unify and push into the midend, but that hasn't been 
done, so you would be writing all your own code, from scratch in the 
frontend.  if you can express a way that hooks into the backend, love 
to hear it, I am unaware of any issues.

Put another way, by the time you lower to RTL, all notion of type 
disappears.  In RTL, you have modes, that's about it.

Now, when I say it is trivial, I mean, all you have to do it write your 
own frontend, which is hard enough, though, trivial.  Non-trivial would 
be, you want to do EH, and the backend doesn't know about it, and you 
want a certain codegen model, say zero overhead, but the backend must 
be altered to be aware of it, and not do certain things in certain 
situations when certain EH constructs are present.  This requires that 
you do the frontend work, trivial, and then `fix' the backend to be 
aware of it, and get everyone else to buy into it.

> * No user written header files, instead the compiler will emit the
> necessary information.  When no optimizations are used it will only 
> emit
> function phototypes and the like.  When using optimization it will emit
> more such as function definitions for functions which are good inlining
> candidates.

Purely a frontend issue.

> * An optional garbage collector.

Like, say java, C or C++, been there, done that, next.

> * Very precise typing of objects.

See above.  Type is a figment of the frontend.

> Types can be limited by arbitrary
> boolean expressions such as limiting an integer to a particular range. 
>  If
> the compiler can not verify the conditions at compile time it is 
> expected
> to be able to optionally emit code to check for it at runtime.

Hum, maybe the mudflap people and the Ada people can chime in here.  My 
take, for performance, you want certain optimization beef (value range 
tracking?), but other than that, this is eye-candy in the frontend, 
hence trivial.  The optimization part would be exceptionally nice to 
have added to gcc, however, if you target C, you don't get the 
optimization for free either, so this cannot influence the choice to 
target C or gcc.

Now, since I've not seen the one person chime in yet who I think you 
should really listen to; let me prompt him to step forward, he's 
written such a frontend and experienced the fun of doing it both ways 
as I recall.  Try google with Mercury gcc frontend Fergus language 
generate C code, and see what you get, just in case he's written up his 
experiences for you already.