• Mahdis (25/25) Mar 20 Hi,
• Iain Buclaw (40/64) Mar 23 To point out a few things you may not already be aware of / offer

Mahdis <ubuntulove74 gmail.com> writes:

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.
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.

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

Iain Buclaw <ibuclaw gdcproject.org> writes:

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.