Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
mir
A lightweight JIT compiler based on MIR (Medium Internal Representation) and C11 JIT compiler and interpreter based on MIR
> No, but new javascript programs are frequently loaded.
This is probably what confuses a lot of people into thinking that program distribution has anything to do with JIT. JavaScript is the only programming language for which the main method of program distribution is source-code-only, and why all the trade-offs of adaptive optimization seem necessary, to the point that now people are making its necessity into a virtue. Likewise for Java stealing credit for popularizing portable bytecode as the main method of program distribution - although Gosling coined the term JIT years before Java had a JIT compiler.
> If (for instance) I write a script in c and run it with tcc -run
And what happens when you use libtcc?
> Compilation should occur concurrently with execution
Execution of what? You do not need an interpreter or a bytecode VM to have a JIT compiler.
> usually accompanied by some heuristic for deciding what to compile first (e.g. tracing)
That is adaptive optimization, and is orthogonal to compiling (you can have adaptive optimizations in an interpreter or a bytecode VM). Tracing (which is not a heuristic btw) is a variation of profile-guided optimization, which is orthogonal to JIT.
> Even if it is not, however, ECL does not JIT c, but produces it statically.
I posted this elsewhere in this thread:
https://gitlab.com/embeddable-common-lisp/ecl/-/blob/develop...
Can you explain why you think that is not a JIT.
> I think that future compiler and VM writers and FPGA soft-CPU authors -- should target this "abstracted instruction set"!
GNU lightning succeeds in what it sets out to do, which is to offer a simple and minimal JIT code-generator. It offers nothing in the way of optimisation, by design. Most projects looking for a code-generator are looking for something with great optimisation built-in, so they're not wrong to go with LLVM or the JVM rather than GNU lightning (or something similar like Mir [0][1]). I don't think the average compiler would gain much by targeting GNU lightning.
With all that said, GNU Guile (a Scheme interpreter) uses a fork of GNU lightning, insufferably named lightening. [0]
[0] https://github.com/vnmakarov/mir
[1] https://lists.gnu.org/archive/html/lightning/2020-02/msg0001...
[2] https://wingolog.org/archives/2019/05/24/lightening-run-time...
Guile uses lightening (with an "e"), which is derived from GNU lightning: https://gitlab.com/wingo/lightening