GNU lightning: generates assembly language code at run-time

There's both a COPYING file that has the GPLv3 in it, and a COPYING.LESSER file with the LGPL in it. I can't tell what's meant by that. Dual licensed? Or portions GPLv3 and portions LGPL?

Why does it only have six registers? The end user probably doesn't want to write a register allocator.

Does anyone know how this compares with libgccjit ? What are the difference in their use cases?<p>(I note that Guile picked lightning, and emacs chose libgccjit for instance for what seems to be similar roles.)

GNU Guile (known primarily for its Scheme implementation) uses a modified version Lightning under the hood.

There was a similar JIT library written in C mentioned on HN awhile ago. Wasnt libjit or lightning. I forget what it was called. Seemed a lot simpler.

<a href="https:&#x2F;&#x2F;www.gnu.org&#x2F;software&#x2F;lightning&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.gnu.org&#x2F;software&#x2F;lightning&#x2F;</a><p>&gt;&quot;GNU lightning is a library that generates assembly language code at run-time; it is very fast, making it ideal for Just-In-Time compilers, and it<p><i>abstracts over the target CPU</i><p>, as it exposes to the clients a standardized RISC instruction set inspired by the MIPS and SPARC chips.&quot;<p>[...]<p>&gt;&quot;GNU lightning is usable in complex code generation tasks. The available backends cover the aarch64, alpha, arm, hppa, ia64, mips, powerpc, risc-v, s390, sparc and x86 architectures.&quot;<p><a href="https:&#x2F;&#x2F;www.gnu.org&#x2F;software&#x2F;lightning&#x2F;manual&#x2F;lightning.html" rel="nofollow">https:&#x2F;&#x2F;www.gnu.org&#x2F;software&#x2F;lightning&#x2F;manual&#x2F;lightning.html</a><p>&gt;&quot;To be portable,<p><i>GNU lightning abstracts over current architectures’ quirks and unorthogonalities.</i><p>The interface that it exposes to is that of a standardized RISC architecture loosely based on the SPARC and MIPS chips. There are a few general-purpose registers (six, not including those used to receive and pass parameters between subroutines), and arithmetic operations involve three operands—either three registers or two registers and an arbitrarily sized immediate value.<p><i>On one hand, this architecture is general enough that it is possible to generate pretty efficient code even on CISC architectures such as the Intel x86 or the Motorola 68k families.</i><p>On the other hand, it matches real architectures closely enough that, most of the time, the compiler’s constant folding pass ends up generating code which assembles machine instructions without further tests.&quot;<p>[...]<p>&gt;&quot;3 GNU lightning’s instruction set<p>GNU lightning’s instruction set was designed by deriving instructions that closely match those of most existing RISC architectures, or that can be easily syntesized if absent. Each instruction is composed of:<p>an operation, like sub or mul most times, a register&#x2F;immediate flag (r or i) an unsigned modifier (u), a type identifier or two, when applicable. Examples of legal mnemonics are addr (integer add, with three register operands) and muli (integer multiply, with two register operands and an immediate operand). Each instruction takes two or three operands; in most cases, one of them can be an immediate value instead of a register.<p>Most GNU lightning integer operations are signed wordsize operations, with the exception of operations that convert types, or load or store values to&#x2F;from memory. When applicable, the types and C types are as follow:<p><pre><code> _c signed char _uc unsigned char _s short _us unsigned short _i int _ui unsigned int _l long _f float _d double </code></pre> Most integer operations do not need a type modifier, and when loading or storing values to memory there is an alias to the proper operation using wordsize operands, that is, if ommited, the type is int on 32-bit architectures and long on 64-bit architectures. Note that lightning also expects sizeof(void*) to match the wordsize.<p>When an unsigned operation result differs from the equivalent signed operation, there is a the _u modifier.<p>There are at least seven integer registers, of which six are general-purpose, while the last is used to contain the frame pointer (FP). The frame pointer can be used to allocate and access local variables on the stack, using the allocai or allocar instruction.<p>Of the general-purpose registers, at least three are guaranteed to be preserved across function calls (V0, V1 and V2) and at least three are not (R0, R1 and R2).<p><i>Six registers are not very much, but this restriction was forced by the need to target CISC architectures which, like the x86</i><p>[PDS: I think despite this trade-off, that this was a <i>good engineering decision(!)</i>, otherwise x86 could not be targeted, and that would destroy a huge swath of functionality!]<p>, are poor of registers; anyway, backends can specify the actual number of available registers with the calls JIT_R_NUM (for caller-save registers) and JIT_V_NUM (for callee-save registers).<p>There are at least six floating-point registers, named F0 to F5. These are usually caller-save and are separate from the integer registers on the supported architectures; on Intel architectures, in 32 bit mode if SSE2 is not available or use of X87 is forced, the register stack is mapped to a flat register file. As for the integer registers, the macro JIT_F_NUM yields the number of floating-point registers.<p>The complete instruction set follows; as you can see, most non-memory operations only take integers (either signed or unsigned) as operands;<p><i>this was done in order to reduce the instruction set</i><p>[PDS: Opinion: Any way that the instruction set can be simplified is a good thing!]<p>, and because most architectures only provide word and long word operations on registers. There are instructions that allow operands to be extended to fit a larger data type, both in a signed and in an unsigned way.&quot;<p>[...]<p>&gt;&quot;8 Acknowledgements<p>As far as I know, the first general-purpose portable dynamic code generator is DCG, by Dawson R. Engler and T. A. Proebsting. Further work by Dawson R. Engler resulted in the VCODE system; unlike DCG, VCODE used no intermediate representation and directly inspired GNU lightning.<p>Thanks go to Ian Piumarta, who kindly accepted to release his own program CCG under the GNU General Public License, thereby allowing GNU lightning to use the run-time assemblers he had wrote for CCG. CCG provides a way of dynamically assemble programs written in the underlying architecture’s assembly language. So it is not portable, yet very interesting.<p>I also thank Steve Byrne for writing GNU Smalltalk, since GNU lightning was first developed as a tool to be used in GNU Smalltalk’s dynamic translator from bytecodes to native code.&quot;<p>[...]<p>PDS: Overall, looks like a great idea!<p>Also, I think that future compiler and VM writers and FPGA soft-CPU authors -- should target this &quot;abstracted instruction set&quot;!<p>Keywords: Instruction Set Architecture, ISA, x86, RISC, RISC-V, Abstraction, Abstract Instruction Set, Instruction Set Subset, Generic Compatibility Layer

I believe Guile and GNU Smalltalk used to run on lightning, do they still do?<p>What other projects use GNU lightning these days?

Documentation was last updated in September, 2019

Too bad it&#x27;s GPL, is there something like this that&#x27;s MIT, BSD, or Apache licensed?

Has had 6 commits in the last two years. From the same person. 2.1.0 was released 6 years ago, the latest 2.1.3 release came out two years ago. Releases are available from some random FTP server.<p>On one hand this could be software that is completely done and requires no more maintenance. On the other hand it could be another random half-baked GNU project with a single champion who has lost interest but is still saddled with a purist&#x2F;terrible new contributor onboarding experience dooms it to an inevitable grave.<p>You can be the judge of that.