About this crate

What is the purpose of this crate? As the name suggests, it implements a cranelift-based JIT backend for the EDL language.

Why cranelift and not LLVM? There are several reasons as to why Cranelift is a better fit for this project then LLVM. The most important ones are listed below:

1. Embedded compiler: Cranelift is meant to be embedded into the application it is used in. With this, it is much simpler to build and install a Cranelift powered application than it is to use an LLVM powered JITTER, since LLVM needs to be linked against statically compiled binaries with have to be pre-installed on the system.

2. Sandboxing: EDL needs to be somewhat mobile by definition and mobile code should never be trusted. LLVM is build for maximal performance trough aggressive optimizations. Cranelift, on the other hand, uses less aggressive optimization tactics and much better hardened against security vulnerabilities than LLVM, since it is used for sandboxed WASM JIT code generation and execution.

3. Compiletime and hot-reloading: Quick feedback is vital for a good user experience, especially for users that are inexperienced with software development. Since EDL is a scripting language that generally aims to be accessible to non-tech people, the EDL compiler pipeline to execution should be as fast as possible. Not only is Cranelift much faster than LLVM in code generation, but it also supports hot-swapping of components in its JIT executor, which is nice for even faster feedback.

4. WASM: Cranelift can be executed in a WASM environment, while LLVM generally cannot. Since EDL is meant to be written in a browser window, Cranelift is much better suited for this purpose than LLVM

5. Performance: while LLVM generally generates better optimized and slightly faster code than Cranelift does, is the performance discrepancy not huge. Especially with EDL and its own MIR-level code transformation, the difference between LLVM generated code and Cranelift generated code should not be large, since most EDL programs result basically on a sequence of calls to external functions. To add to this, the vast majority of the runtime of the program will be spend evaluating these external functions, while the time spend in the actual EDL program is typically negligible.

Panic unwinding in EDL work based on a global panic handler that is located at a special location. The format of the panic handler is described in the following sections:

Legacy Format

In the legacy format (currently implemented) the panic handler is only really valid for single threaded programs, as all threads look for the same panic indicator. The stack consists of a 2 byte header followed by n stack messages.

New Format

Switching to a new format has two reasons; for one, panics should behave correctly for multithreaded programs - if a thread panics that panic should only be unwound for that thread with all other threads ignoring the panic all together. Secondly, the position of the error on the source code should be encoded separately so that the error messages may be formatted nicely for reporting.

Header

Active Panic Table

Trace Pool

trace entry