The C runtime is pretty much all OS-interaction support components.
IIRC, none of the actual ANSI CL code is implemented in C - in fact, it would break one of the core design ideas of SBCL, which is "Sanely Bootstrappable" - SBCL can compile itself on any "complete enough" ANSI CL system - it doesn't even have to implement everything - then uses itself and its own standard library to compile itself again but into actual native code.
Out of memory, the C based runtime in SBCL has the garbage collector, low-level memory interfaces to OS (how to acquire memory, how to release memory, setting memory protection flags), some core FFI to OS which are called pretty deep from standard library (i/o, threads, processes), basic FFI supports (manipulating linkage tables, for example) setting CPU contexts, etc.
On the non-OS-specific side, there's core loading, which is a distant ancestor of Mach dynamic linker.
Some of it is C-side implementation of basic SBCL datatypes which allows both GC and runtime to interact with them safely, but usually the CL code does not call into those.
Some of the low-level manipulation is actually assembler.
Thanks, that’s very helpful! I wish people would write detailed implementation books about these things as it is very hard to get into when just jumping in the deep even for experienced C and Lisp programmers. I guess I need to jump in!
For starters, SBCL's non-CL parts are separated into src/runtime directory, which makes it much easier to figure out what is just "support structure" and what is actual language.
For learning more specifically on SBCL, you can look at following
There are also some papers related to CMUCL (and before that, Spice Lisp) that talk about Python Compiler (the compiler used by CMU CL, SBCL, Scieneer CL)
IIRC, none of the actual ANSI CL code is implemented in C - in fact, it would break one of the core design ideas of SBCL, which is "Sanely Bootstrappable" - SBCL can compile itself on any "complete enough" ANSI CL system - it doesn't even have to implement everything - then uses itself and its own standard library to compile itself again but into actual native code.
Out of memory, the C based runtime in SBCL has the garbage collector, low-level memory interfaces to OS (how to acquire memory, how to release memory, setting memory protection flags), some core FFI to OS which are called pretty deep from standard library (i/o, threads, processes), basic FFI supports (manipulating linkage tables, for example) setting CPU contexts, etc.
On the non-OS-specific side, there's core loading, which is a distant ancestor of Mach dynamic linker.
Some of it is C-side implementation of basic SBCL datatypes which allows both GC and runtime to interact with them safely, but usually the CL code does not call into those.
Some of the low-level manipulation is actually assembler.