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.
