Writing a GCC Front End with D!

[Iain Buclaw]

On Wednesday, 20 March 2024 at 13:19:27 UTC, Mahdis wrote:
> Hi,
>
> I have a question about the possibility of developing a new 
> frontend language for GIMPLE in GCC using D instead of C++.
>

To point out a few things you may not already be aware of / offer 
some thoughts in what I hope reads as neutral.

> I'm interested in exploring this possibility because D offers 
> several advantages over C++, including:
>
> 1. Memory safety: D's garbage collector eliminates the need for 
> manual memory management, which can help to prevent common 
> errors such as memory leaks and dangling pointers.

GCC does have a garbage collector though (GGC), the interaction 
with it is to tag global variables and types with `GTY(())` to 
let it know where the roots are, and how to traverse them to look 
for more GC allocated memory.

> 2.Expressiveness: D's syntax is more concise and expressive 
> than C++'s, which can make code easier to read, write, and 
> maintain.

Can't argue with that. :-)

> 3. Modern features: D supports many modern programming 
> features, such as generics, templates, and metaprogramming, 
> which can be used to write more powerful and flexible code.
>

GCC has been embracing more of this though since making C++-11 
the bootstrap version, with some talk about bumping it to C++-14.

That's not to say this is a justification for not using D though, 
and using C++ traits can be described as jagged at best.

> I believe that developing a new frontend language for GIMPLE in 
> D would be a valuable contribution to the GCC project. It would 
> allow developers to take advantage of D's many benefits while 
> still using GCC's powerful optimization and code generation 
> capabilities.
>

There is the binding problem though, as GCC internals do not have 
a stable layout. The API for interacting with GENERIC is just 
forest of macros (see gcc/tree.h) that hide all changes that are 
going on under the hood.  These will need to be accounted for, 
and I don't expect ImportC won't help you extract these 
definitions out of the C++ headers either.

> I would be grateful for any information you can provide about 
> the feasibility of this project. Thank you for your time and 
> consideration.
> Considering that I have no knowledge in this field, I would 
> like to know if there are any limitations in this field.
>

Not saying it can't be done, but there's an extra maintenance 
needed to keep the front-end written in D in sync with the GCC 
middle-end. Gnat achieves this with a library named Gigi to bind 
these as functions callable from Ada.

Think something like:
```d
extern(C++) ref tree type_attributes(tree);
```

```c++
tree &type_attributes(tree node) { return TYPE_ATTRIBUTES(node); }
```

Though I don't actually know to what extent they do something 
like the above, or whether the GCC interface is even more high 
level.

I've also seen an Algol front-end for GCC written in Algol 
itself, and the author of chose to translate all macros it used 
into Algol directly, the downside then is that it's tying itself 
to a specific version of GCC.

Writing a GCC plugin in D might be a good idea to test the waters 
for whichever method works best before going full language 
front-end.

Iain.