Question about code generation

Question about code generation

[Gerd Möllmann]

I'm wondering if it has ever been considered or tried in the last 20
years to generate code for Emacs using C parse trees of its sources?

I'm thinking of things like GC marking functions, dump functions, copy
functions an alike for structs.

SWIG could be used for example which can produce parse trees as XML.

Re: Question about code generation

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Fri, 10 May 2024 11:33:43 +0200
> 
> I'm wondering if it has ever been considered or tried in the last 20
> years to generate code for Emacs using C parse trees of its sources?

Isn't that what the C compiler does?

But I guess I'm misunderstanding what you are asking about.

Re: Question about code generation

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Date: Fri, 10 May 2024 11:33:43 +0200
>> 
>> I'm wondering if it has ever been considered or tried in the last 20
>> years to generate code for Emacs using C parse trees of its sources?
>
> Isn't that what the C compiler does?
>
> But I guess I'm misunderstanding what you are asking about.

I was thinking of (making my life easier and) generating the fix_
functions in igc.c, as an example, from knowledge that a C parser has
which members are in a given struct, what's their type, Lisp_Object,
pointer to something interesting, ...

Together with meta infos passed to a code generator this could be used
for all sorts of things, I guess.

Re: Question about code generation

[Helmut Eller]

On Fri, May 10 2024, Gerd Möllmann wrote:

>> But I guess I'm misunderstanding what you are asking about.
>
> I was thinking of (making my life easier and) generating the fix_
> functions in igc.c, as an example, from knowledge that a C parser has
> which members are in a given struct, what's their type, Lisp_Object,
> pointer to something interesting, ...
>
> Together with meta infos passed to a code generator this could be used
> for all sorts of things, I guess.

Would be nice to write things like:

struct foo {
   void* bar [[emacs::igc_fix_obj]];
}

and then run a gcc or clang plugin over it and generate the needed code.

Can libgccjit be used to parse C code and could we write the plugin in
Emacs Lisp?  That would be fun.

Re: Question about code generation

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

> On Fri, May 10 2024, Gerd Möllmann wrote:
>
>>> But I guess I'm misunderstanding what you are asking about.
>>
>> I was thinking of (making my life easier and) generating the fix_
>> functions in igc.c, as an example, from knowledge that a C parser has
>> which members are in a given struct, what's their type, Lisp_Object,
>> pointer to something interesting, ...
>>
>> Together with meta infos passed to a code generator this could be used
>> for all sorts of things, I guess.
>
> Would be nice to write things like:
>
> struct foo {
>    void* bar [[emacs::igc_fix_obj]];
> }

Yeah, exactly!

>
> and then run a gcc or clang plugin over it and generate the needed code.
>
> Can libgccjit be used to parse C code and could we write the plugin in
> Emacs Lisp?  That would be fun.

Re: Question about code generation

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Fri, 10 May 2024 14:57:17 +0200
> 
> On Fri, May 10 2024, Gerd Möllmann wrote:
> 
> >> But I guess I'm misunderstanding what you are asking about.
> >
> > I was thinking of (making my life easier and) generating the fix_
> > functions in igc.c, as an example, from knowledge that a C parser has
> > which members are in a given struct, what's their type, Lisp_Object,
> > pointer to something interesting, ...
> >
> > Together with meta infos passed to a code generator this could be used
> > for all sorts of things, I guess.
> 
> Would be nice to write things like:
> 
> struct foo {
>    void* bar [[emacs::igc_fix_obj]];
> }
> 
> and then run a gcc or clang plugin over it and generate the needed code.
> 
> Can libgccjit be used to parse C code and could we write the plugin in
> Emacs Lisp?  That would be fun.

AFAIU, libgccjit needs GIMPL, and you drive it by calling the
respective functions from libgccjit.  But Andrea will tell for sure.

Re: Question about code generation

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Helmut Eller <eller.helmut@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Fri, 10 May 2024 14:57:17 +0200
>> 
>> On Fri, May 10 2024, Gerd Möllmann wrote:
>> 
>> >> But I guess I'm misunderstanding what you are asking about.
>> >
>> > I was thinking of (making my life easier and) generating the fix_
>> > functions in igc.c, as an example, from knowledge that a C parser has
>> > which members are in a given struct, what's their type, Lisp_Object,
>> > pointer to something interesting, ...
>> >
>> > Together with meta infos passed to a code generator this could be used
>> > for all sorts of things, I guess.
>> 
>> Would be nice to write things like:
>> 
>> struct foo {
>>    void* bar [[emacs::igc_fix_obj]];
>> }
>> 
>> and then run a gcc or clang plugin over it and generate the needed code.
>> 
>> Can libgccjit be used to parse C code and could we write the plugin in
>> Emacs Lisp?  That would be fun.
>
> AFAIU, libgccjit needs GIMPL, and you drive it by calling the
> respective functions from libgccjit.  But Andrea will tell for sure.

I think in this case libgccjit goes the other way of what would be need
here.  Libgccjit allowed us to develop an Elisp front-end while here the
frontend we need is already the C one that comes with GCC.

What we want is a GCC plugin, essentially a custom pass that analyses
say lisp.h and output something (in this case some C code).

Not many people know that should be even possible to write it in python
thanks to David Malcolm work
<https://gcc-python-plugin.readthedocs.io/en/latest/>, certanly not
Elisp :/ but probably quicker than doing it in C.

Thanks

  Andrea

Re: Question about code generation

[tomas]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

On Fri, May 10, 2024 at 01:00:51PM -0400, Andrea Corallo wrote:

[...]

> I think in this case libgccjit goes the other way of what would be need
> here.  Libgccjit allowed us to develop an Elisp front-end while here the
> frontend we need is already the C one that comes with GCC.
> 
> What we want is a GCC plugin, essentially a custom pass that analyses
> say lisp.h and output something (in this case some C code).
> 
> Not many people know that should be even possible to write it in python
> thanks to David Malcolm work
> <https://gcc-python-plugin.readthedocs.io/en/latest/>, certanly not
> Elisp :/ but probably quicker than doing it in C.

And then, there is MELT [1], by Basile Starynkevitch, which, AFAIR is
a Lispy GCC plugin.

Cheers

[1] https://gcc.gnu.org/wiki/MiddleEndLispTranslator
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Question about code generation

[Andrea Corallo]

<tomas@tuxteam.de> writes:

> On Fri, May 10, 2024 at 01:00:51PM -0400, Andrea Corallo wrote:
>
> [...]
>
>> I think in this case libgccjit goes the other way of what would be need
>> here.  Libgccjit allowed us to develop an Elisp front-end while here the
>> frontend we need is already the C one that comes with GCC.
>> 
>> What we want is a GCC plugin, essentially a custom pass that analyses
>> say lisp.h and output something (in this case some C code).
>> 
>> Not many people know that should be even possible to write it in python
>> thanks to David Malcolm work
>> <https://gcc-python-plugin.readthedocs.io/en/latest/>, certanly not
>> Elisp :/ but probably quicker than doing it in C.
>
> And then, there is MELT [1], by Basile Starynkevitch, which, AFAIR is
> a Lispy GCC plugin.
>
> Cheers
>
> [1] https://gcc.gnu.org/wiki/MiddleEndLispTranslator

Is MELT still a thing?  Should be inactive since 2017 according to
<http://starynkevitch.net/basile/gcc-melt/>

  Andrea

Re: Question about code generation

[Andrea Corallo]

Andrea Corallo <acorallo@gnu.org> writes:

> <tomas@tuxteam.de> writes:
>
>> On Fri, May 10, 2024 at 01:00:51PM -0400, Andrea Corallo wrote:
>>
>> [...]
>>
>>> I think in this case libgccjit goes the other way of what would be need
>>> here.  Libgccjit allowed us to develop an Elisp front-end while here the
>>> frontend we need is already the C one that comes with GCC.
>>> 
>>> What we want is a GCC plugin, essentially a custom pass that analyses
>>> say lisp.h and output something (in this case some C code).
>>> 
>>> Not many people know that should be even possible to write it in python
>>> thanks to David Malcolm work
>>> <https://gcc-python-plugin.readthedocs.io/en/latest/>, certanly not
>>> Elisp :/ but probably quicker than doing it in C.
>>
>> And then, there is MELT [1], by Basile Starynkevitch, which, AFAIR is
>> a Lispy GCC plugin.
>>
>> Cheers
>>
>> [1] https://gcc.gnu.org/wiki/MiddleEndLispTranslator
>
> Is MELT still a thing?  Should be inactive since 2017 according to
> <http://starynkevitch.net/basile/gcc-melt/>

And it's successor doesn't look very active either
<https://github.com/bstarynk/bismon>

  Andrea

Re: Question about code generation

[tomas]

[-- Attachment #1: Type: text/plain, Size: 270 bytes --]

On Fri, May 10, 2024 at 01:35:18PM -0400, Andrea Corallo wrote:
> <tomas@tuxteam.de> writes:

[MELT]

> Is MELT still a thing?  Should be inactive since 2017 according to
> <http://starynkevitch.net/basile/gcc-melt/>

Oh, that's sad.

Thanks & cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]