Hi folks! Please reply AOT topic in this thread. > 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 :) Thanks for the work! At least in Guile community, now that we already have JIT with GNU Lightening, we won't redundantly talk libgccjit for JIT. But I think it's still interesting to try libgccjit for JIT in my other project. :-p > Probably of most interest to guile developers might be the gccemacs project here: https://akrl.sdf.org/gccemacs.html It looks super interesting! They created a high level IR just like GIMPLE, which named LIMPLE. It's the way I preferred in streaming-fist. The basic idea is to provide such an IR, then try to replace 'bytecode' in Guile compiler tower codegen. And they choose SBCL for it, I think it can inspire people who are interested in Guile AOT. Or maybe they could consider to change to Guile to save a lot of time for both Guile and Emacs. The compiler tower is so flexible that it's possible to try it as a plugin. I agreed with @mikael about losing weight of Guile. The AOT feature can be a plugin to install as guild tools. Of course, plugin unnecessarily mean it will be small...... Best regards. On Sun, Dec 15, 2024, 02:45 Nala Ginrut wrote: > Thanks for the inspiring sharing! 👏 > > On Sun, Dec 15, 2024, 02:39 Basile Starynkevitch > wrote: > >> On Sun, 2024-12-15 at 02:21 +0900, Nala Ginrut wrote: >> >> @basile I'm glad you raise this topic, I've played lobgccjit with a toy >> project. >> https://gitlab.com/hardenedlinux/screaming-fist >> >> I would say libgccjit is a wrong name since it's more like a tool for AOT. >> Of course, one may still use it for JIT, however you have to do your own >> work for JIT and finally use libgccjit for codegen. 😁 >> >> Best regards. >> >> >> You basically are right. If you want to use get a fast just-in-time >> compilation, libgccjit might not be the right tool. >> >> But in practice, current computers are so fast that I think that in >> practice libgccjit is quite usable, and it can be tuned to various GCC >> optimization strategy. >> >> A few years ago I did experiment (see https://arxiv.org/abs/1109.0779 ...) >> generation of C++ code which (on Linux desktop) was GCC compiled to a >> plugin and dlopen-ed. This works quite well with an elapsed time suitable >> for human users. >> >> A related experiment is my manydl.c thing on >> https://github.com/bstarynk/misc-basile - it is/was a toy program that I >> wrote which generates a lot of random C code (in many thousands of C >> files), compile it to a plugin, and use dlopen and dlsym. It shows that on >> Linux a process can successfully dlopen do many hundred thousands of >> plugins (and never bother dlclose-ing them) >> >> BTW in France the Lisp syntax and Scheme semantics of GNU guile is sadly >> becoming impopular. I know few persons using it. >> >> Just in case I am attaching a few PDF files on RefPerSys. >> >> Some ideas of RefPerSys originated from books and papers by by Jacques >> Pitrat >> https://en.wikipedia.org/wiki/Jacques_Pitrat >> >> Please mention RefPerSys to your colleagues and forward them this email. >> >> Thanks >> >> >> >> ---------- Forwarded message --------- >> From: Basile Starynkevitch >> Date: Sun, Dec 15, 2024, 02:11 >> Subject: Re: Running Compiled Guile Objects >> To: Nala Ginrut , Hakan Candar < >> hakancandar-g/b1ySJe57IN+BqQ9rBEUg@public.gmane.org> >> Cc: guile-user-mXXj517/zsQ@public.gmane.org , >> >> >> 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. >> > >> >> 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/ >> >> 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. >> >> 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) >> >> >> -- >> >> Basile STARYNKEVITCH 8 rue de la Faïencerie >> 92340 Bourg-la-Reine, France http://starynkevitch.net/Basile & https://github.com/bstarynk >> >>