Discussing gcc font end hobby project

Discussing gcc font end hobby project

[Miro Palmu]

Hi.

I have a idea about long term hobby project relating to gcc,
so with this email I'm asking feedback about the idea
early rather than later. First little bit of context.

I'm a student deep in a university course about compilers
and I have been writing a compiler for language
which is a subset of Herb Sutter's Cpp2.
I chose this because I'm bit of a Cpp language nerd,
and I can apply all of my Cpp knowledge to this project, which is fun.

After the course I'm interested in converting this to a front end to gcc,
with goal of learning about front end development to gcc.
(It is a non-goal to try to upstream the project.)

I don't see any obvious reason why this would not be possible.
It just need to be able to target (C++ version of ?) GENERIC.
This would be the first goal of the compiler
and would serve as the MVP of the project.
Below is discussing/theorizing post MVP goals.

Because the Herb Sutter's cppfront transpiles Cpp2 to Cpp1,
it is easy to have mix of Cpp1 and Cpp2 global level constructs
in the same file. Just generate forward declarations of everything,
keep Cpp1 definitions unchanged and transpile the Cpp2 ones.

At the moment my subset Cpp2 does not support this compatibility
but it would be nice to have at some point.
But if my front end targets GENERIC I would have to use g++ machinery
to turn the Cpp1 parts to GENERIC and then somehow combine the trees.
I imagine that somebody with more experienced with GENERICs would have
a intuition on how hard this combinations would be to implement.
I'm curious about this intuition which I lack.

In Cpp2 one can import and export Cpp1 modules. With transpiling to
Cpp1 this again is easy implement but with potential front end,
I'm not sure. I'm quite ignorant on Compiled Module Interface (CMI)
implementation in gcc, so I'm asking just for guidance on where to look
if one would want to learn on how CMIs are implemented.

Thanks!

-- 
Miro Palmu

Re: Discussing gcc font end hobby project

[Richard Biener]

On Fri, Feb 23, 2024 at 10:22 AM Miro Palmu via Gcc <gcc@gcc.gnu.org> wrote:
>
> Hi.
>
> I have a idea about long term hobby project relating to gcc,
> so with this email I'm asking feedback about the idea
> early rather than later. First little bit of context.
>
> I'm a student deep in a university course about compilers
> and I have been writing a compiler for language
> which is a subset of Herb Sutter's Cpp2.
> I chose this because I'm bit of a Cpp language nerd,
> and I can apply all of my Cpp knowledge to this project, which is fun.
>
> After the course I'm interested in converting this to a front end to gcc,
> with goal of learning about front end development to gcc.
> (It is a non-goal to try to upstream the project.)
>
> I don't see any obvious reason why this would not be possible.
> It just need to be able to target (C++ version of ?) GENERIC.
> This would be the first goal of the compiler
> and would serve as the MVP of the project.
> Below is discussing/theorizing post MVP goals.

Note there is no textual form of GENERIC that a GCC compiler
binary could parse.  So your Cpp compiler would need to build
GENERIC data structures itself, basically be a real GCC language frontend.
The alternative is to use GCCs JIT but that emits GIMPLE only
(I think there's a rust frontend project that tries to leverage that,
and also GNU emacs is using it).

> Because the Herb Sutter's cppfront transpiles Cpp2 to Cpp1,
> it is easy to have mix of Cpp1 and Cpp2 global level constructs
> in the same file. Just generate forward declarations of everything,
> keep Cpp1 definitions unchanged and transpile the Cpp2 ones.
>
> At the moment my subset Cpp2 does not support this compatibility
> but it would be nice to have at some point.
> But if my front end targets GENERIC I would have to use g++ machinery
> to turn the Cpp1 parts to GENERIC and then somehow combine the trees.
> I imagine that somebody with more experienced with GENERICs would have
> a intuition on how hard this combinations would be to implement.
> I'm curious about this intuition which I lack.
>
> In Cpp2 one can import and export Cpp1 modules. With transpiling to
> Cpp1 this again is easy implement but with potential front end,
> I'm not sure. I'm quite ignorant on Compiled Module Interface (CMI)
> implementation in gcc, so I'm asking just for guidance on where to look
> if one would want to learn on how CMIs are implemented.

There's no generic code for implementing CMIs, each frontend requiring such
does need to implement that on its own.

Hope this helps,
Richard.

> Thanks!
>
> --
> Miro Palmu

Re: Discussing gcc font end hobby project

[David Malcolm]

On Tue, 2024-02-27 at 10:15 +0100, Richard Biener via Gcc wrote:
> On Fri, Feb 23, 2024 at 10:22 AM Miro Palmu via Gcc <gcc@gcc.gnu.org>
> wrote:
> > 
> > Hi.
> > 
> > I have a idea about long term hobby project relating to gcc,
> > so with this email I'm asking feedback about the idea
> > early rather than later. First little bit of context.
> > 
> > I'm a student deep in a university course about compilers
> > and I have been writing a compiler for language
> > which is a subset of Herb Sutter's Cpp2.
> > I chose this because I'm bit of a Cpp language nerd,
> > and I can apply all of my Cpp knowledge to this project, which is
> > fun.
> > 
> > After the course I'm interested in converting this to a front end
> > to gcc,
> > with goal of learning about front end development to gcc.
> > (It is a non-goal to try to upstream the project.)
> > 
> > I don't see any obvious reason why this would not be possible.
> > It just need to be able to target (C++ version of ?) GENERIC.
> > This would be the first goal of the compiler
> > and would serve as the MVP of the project.
> > Below is discussing/theorizing post MVP goals.
> 
> Note there is no textual form of GENERIC that a GCC compiler
> binary could parse.  So your Cpp compiler would need to build
> GENERIC data structures itself, basically be a real GCC language
> frontend.
> The alternative is to use GCCs JIT but that emits GIMPLE only

FWIW libgccjit does build GENERIC internally, rather than GIMPLE, but
hides it all behind an API; the pertinent code is in gcc/jit/jit-
playback.{cc,h}

> (I think there's a rust frontend project that tries to leverage that,
> and also GNU emacs is using it).

[...]
> 

Re: Discussing gcc font end hobby project

[Miro Palmu]

On 2024-02-27 11:15, Richard Biener via Gcc wrote:
> On Fri, Feb 23, 2024 at 10:22 AM Miro Palmu via Gcc <gcc@gcc.gnu.org> wrote:
>>
>> Hi.
>>
>> I have a idea about long term hobby project relating to gcc,
>> so with this email I'm asking feedback about the idea
>> early rather than later. First little bit of context.
>>
>> I'm a student deep in a university course about compilers
>> and I have been writing a compiler for language
>> which is a subset of Herb Sutter's Cpp2.
>> I chose this because I'm bit of a Cpp language nerd,
>> and I can apply all of my Cpp knowledge to this project, which is fun.
>>
>> After the course I'm interested in converting this to a front end to gcc,
>> with goal of learning about front end development to gcc.
>> (It is a non-goal to try to upstream the project.)
>>
>> I don't see any obvious reason why this would not be possible.
>> It just need to be able to target (C++ version of ?) GENERIC.
>> This would be the first goal of the compiler
>> and would serve as the MVP of the project.
>> Below is discussing/theorizing post MVP goals.
> 
> Note there is no textual form of GENERIC that a GCC compiler
> binary could parse.  So your Cpp compiler would need to build
> GENERIC data structures itself, basically be a real GCC language frontend.

Yes, that is my plan. This is little late reply, so I had already
started the conversion last week and at the moment I have the
boilerplate implemented for the front end.

> The alternative is to use GCCs JIT but that emits GIMPLE only
> (I think there's a rust frontend project that tries to leverage that,
> and also GNU emacs is using it).
 
That is interesting. Have to read more about it, thanks for mentioning!

>> Because the Herb Sutter's cppfront transpiles Cpp2 to Cpp1,
>> it is easy to have mix of Cpp1 and Cpp2 global level constructs
>> in the same file. Just generate forward declarations of everything,
>> keep Cpp1 definitions unchanged and transpile the Cpp2 ones.
>>
>> At the moment my subset Cpp2 does not support this compatibility
>> but it would be nice to have at some point.
>> But if my front end targets GENERIC I would have to use g++ machinery
>> to turn the Cpp1 parts to GENERIC and then somehow combine the trees.
>> I imagine that somebody with more experienced with GENERICs would have
>> a intuition on how hard this combinations would be to implement.
>> I'm curious about this intuition which I lack.
>>
>> In Cpp2 one can import and export Cpp1 modules. With transpiling to
>> Cpp1 this again is easy implement but with potential front end,
>> I'm not sure. I'm quite ignorant on Compiled Module Interface (CMI)
>> implementation in gcc, so I'm asking just for guidance on where to look
>> if one would want to learn on how CMIs are implemented.
> 
> There's no generic code for implementing CMIs, each frontend requiring such
> does need to implement that on its own.
>
> Hope this helps,
> Richard.
> 

Yes. Thanks again!

>> Thanks!
>>
>> --
>> Miro Palmu
-- 
Miro Palmu