Re: Running Compiled Guile Objects

[David Malcolm <dmalcolm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On Sat, 2024-12-14 at 18:11 +0100, Basile Starynkevitch wrote:
> On Sat, 2024-12-14 at 09:15 +0900, Nala Ginrut wrote:
> > Hi Hakan!
> > The current Guile is not AOT yet. Although the object file is ELF,
> > it's
> > just bytecode wrapped ELF header. So you can't run it as a regular
> > executable file.
> > 
> 

[Sorry if I'm missing context here, I'm only seeing the part of the
thread where Basile CCed the jit-/MQLu3FmUzdAfugRpC6u6w@public.gmane.org mailing list]

> Those willing to contribute a proper ahead-of-time compiler to GNU
> guile could use the GNU CC libgccjit library which is part of the GCC
> compiler.
> https://gcc.gnu.org/onlinedocs/jit/

...and https://gcc.gnu.org/wiki/JIT

Indeed, it turns out that everyone using libgccjit is using it for
ahead-of-time compilation, rather than jit-compilation.  Sorry about
picking a bad name :)

Probably of most interest to guile developers might be the gccemacs
project here:
  https://akrl.sdf.org/gccemacs.html
since AFAIK that has successfully used libgccjit from within a lisp-
like language to get noticeable speedups.  But guile developers
probably know more about this than I do; I confess I don't know much
about the lisp/scheme world.
> 
> This libgccjit layer of the GCC compiler is stable and maintained C
> API
> and has some obsolete C++ API (which seems unmaintained in december
> 2024). Most of the libgccjit code is internally coded (under GPL
> license) in C++, but the stable API is for C.

Indeed, it is gcc's code generation source code (which is C++), wrapped
in a C API and header (it looks like a frontend to the rest of gcc, and
like an API to the client code).

Hope this is constructive
Dave

> 
> I am using the C API of libgccjit in the RefPerSys open source
> inference engine project (GPLv3+ licensed) on
> https://github.com/RefPerSys/RefPerSys/
> 
> Both libgccjit and GNU lightning (see
> https://www.gnu.org/software/lightning/ ...) could be a basis for
> adding a genuine compilation layer to GNU guile. And RefPerSys uses
> both.
> 
> I guess a significant issue would be to use libgccjit (or GNU
> lightning) with GUILE's garbage collector (which seems to be Boehm
> conservative GC).
> 
> The RefPerSys project has a precise garbage collector and some
> persistence (to textual files). Since it is GPLv3+ licensed, its code
> could be reused in a future GUILE major version. RefPerSys is mostly
> coded in C++.
> 
> I did contribute to GCC long time ago and hope that RefPerSys could
> become a GNU project (but don't know how to make that happen)
> 
> Regards from near Paris in France.
>