Hi,

I have a question about the possibility of developing a new frontend language for GIMPLE in GCC using D instead of C++.

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.
   2.Expressiveness: D's syntax is more concise and expressive than C++'s, which can make code easier to read, write, and maintain.
2. 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.

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.

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.

Sincerely,

Mahdis

On Wednesday, 20 March 2024 at 13:19:27 UTC, Mahdis wrote:

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

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.

Can't argue with that. :-)

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.

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.

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:

extern(C++) ref tree type_attributes(tree);

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.