JITLink: Native Windows JITing in LLVM

JITLink is a new JIT linker in LLVM developed to eliminate limitations in LLVM’s JIT implementation. With JITLink, it is not required to use special compilation flags or workarounds to load code into the JIT, since most of the object file features including small code model and thread local storage are fully implemented. This tutorial will explain how to use JITLink by working on a windows JIT application that just-in-time links to third-party static libraries. The tutorial will also dig into internals of JITLink by working on a JITLink plugin managing SEH exception tables.

jank: A Clojure dialect on LLVM with gradual typing, a native runtime, and C++ interop

Following years of Lisp development, Clojure has entered the scene as a practical Lisp for the JVM. It takes a functional-first approach to designs and has extensive support for purely transforming persistent, immutable data structures. The interactive programming experience Clojure brings to the JVM is unmatched, built on both a JIT and technology such as nREPL. Clojure developers use this interactive programming to build their software from empty source files to working servers, GUI applications, and more without restarting the process. In the spirit of Clojure, I would like to present jank, a research programming language which is a Clojure dialect built on native C++, rather than the JVM, using Cling as its JIT compiler. jank aims to be strongly compatible with Clojure while offering the same interactive programming experience. Like Clojure, jank aims to provide seamless interop with its host (meaning C++), allowing for easy consumption of third-party libraries. On top of a native runtime, jank also aims to provide gradual, structural typing, which will not be covered in this presentation.

ez-clang: experimental C++ REPL for bare metal

In 2021 a new remote-JIT layer “RemoteEPC” landed in LLVM’s OrcJIT library [0]. It separates serialization from transport, streamlines error behavior and integrates well with ExecutorProcessControl. Combined with the clean design and extensibility of ORCv2 and JITLink, it lowers the bar for building exotic out-of-process LLVM bitcode JITs. The ez-clang project [1] makes use of all these to build a pure out-of-process REPL specifically designed for very low-resource embedded devices. The executor endpoint on the device is very simple and fits into a few Kilobytes of memory. All heavy lifting happens in the JIT process on the host. I want to present my proof-of-concept implementation, which is based on a hacked-up version of cling [2] (bringing in Clang-integration, a command line and the concept of transaction-based incremental compilation). Right now, it supports a small selection of Cortex-M development boards. The smallest is the TeensyLC [3] with an ARMv6-M instruction set, 62kb Flash memory and 8kb RAM.
[0] https://github.com/llvm/llvm-project/commit/bb27e4564355
[1] https://echtzeit.dev/ez-clang
[2] https://github.com/root-project/cling
[3] https://www.pjrc.com/teensy/teensyLC.html

Cppyy

cppyy provides automatic Python bindings to C++ code, at runtime, through Cling, the C++ interpreter. Python is itself a dynamic language executed by an interpreter, thus the interaction with C++ code becomes more natural when intermediated by Cling. Examples include runtime template instantiations, callbacks, cross-language inheritance, automatic downcasting, and exception mapping. Many advanced C++ features such as placement new, multiple virtual inheritance, variadic templates, etc., are also naturally handled. cppyy achieves high performance through an all-lazy approach and specialization of common cases through runtime reflection. As such, it has a much lower call overhead than other binders, notably in its implementation for PyPy, a fully compatible Python interpreter sporting a tracing JIT. Furthermore, cppyy makes maintaining a large software stack simpler: except for cppyy’s own python-interpreter binding, it does not have any compiled code that is Python-dependent. I.e., cppyy-based extension modules require no recompilation when switching Python interpreters. In this presentation I’ll show the benefits of runtime Python-C++ bindings and give a bird’s eye overview of the implementation underpinning cppyy.

A brief history of Cxx.jl

Cxx.jl is one of the oldest Julia packages and provides extremely tight integration between Julia and C++. With advanced features including a C++, REPL environment, the ability to perform cross-language template instantiation as well as cross-language object implementation, it is a powerful tool for developers seeking to integrate the two languages. However, despite these capabilities, the package never fully became mainstream due to a number of technical limitations. In this talk, I will explore the design and featureset of Cxx.jl, and what limitations in Clang and Julia prevented its full adoption in the Julia world.

GPU Acceleration of Automatic Differentiation in C++ with Clad

Deep dive into the Xeus-based Cling kernel for Jupyter

Sylvain Corlay from QuantStack talks about C++ in Jupyter Notebooks using the Xeus-Cling. Xeus-Cling is a Cling-based notebook kernel which delivers interactive C++. Sylvain makes a deep dive in topic outlining some of the specific challenges and requirements.

Cling’s CUDA Backend: Interactive GPU development with CUDA C++

Simeon Ehrig from Helmholtz-Zentrum Dresden-Rossendorf (HZDR) shared his work with us recently. In his talk he gives insights about interactive CUDA using the C++ interpreter Cling. He shows several exciting examples in the area of dynamic execution without loss of state where we can “checkpoint” the execution state, add specific data analysis and reuse the previous computations.

Calling C++ libraries from a D-written DSL: A cling/cppyy-based approach

Alexandru Militaru shared his work with us recently. In his talk he gives insights about C++/D interoperability on the fly using the interactive C++ interpreter Cling and cppyy.