Here is my plan to attempt to construct a LISP operating system that will boot on the bare metal from the very first.
Part 1 — Modify the LISP Machine
Section 1 - Deal with the C library interface
Select either EMACS or SBCL as the LISP machine.
Deal with the UNIX system calls using the Uni of Utah’s Operating System Toolkit’s most primitive C function library, as well as its memory allocation library, and the kernel support library.
This will make the LISP machine execute properly on the hardware.
This is not a POSIX compliant system, so i will not be using the Operating System Toolkit’s more extensive C component libraries. Doing this would be making big steps towards reimplementing UNIX underneath the LISP machine, instead of using SBCL or EMACS as the main operating system environment.
The implementation of ML that Albert Lin’s Master’s thesis used had a group of C libraries that performed the interface between the ML compiler and the UNIX kernel. When running in UNIX, these C libraries managed all the system calls.
The Master’s thesis started by replacing all the references to system calls inside the ML C libraries not handled by the OS Toolkit’s minimalist C function library with dummy functions.
Then, these dummy functions were reimplemented using select functions from the OS Toolkit’s minimal POSIX component C library.
EMACS is definitely written in C, and can be treated this way, but I believe SBCL is written, indeed, in Common LISP, so dealing with its system calls will require, perhaps, rewriting small portions of it in its native LISP.
Section 2 - Memory AllocationStep 4 - the OS Toolkit’s ‘LMM’ library
Depending on how EMACS/SBCL requests memory using UNIX system calls, I will follow the Master’s thesis: simply use malloc() and free() to request a big ol’ block of memory at boot, and use the internals of the LISP machine to manage the memory itself.
This way, the most primitive C library from the OS Toolkit, the Limited Memory Management C component library can be used.
This should be fairly trivial.
Part 3 - Set Up the Heap Using the Bootloader
Before we start using a file system, we can just create a memory structure externally, and get the bootloader to load it with an extra boot module.
This way we can get the LISP machine working without having to add any more extra work in order to get the system booting sooner.
Part 4 - Interrupts, Signals and Traps
Use the OS Toolkit’s kernel component library to handle exceptions/interrupts/signals/traps. This step will be similar to the minimalist C library step. The system calls that represent a UNIX signal() call need to be dealt with, and luckily the OS Toolkit has resources for this.
This will allow the interface between the hardware interrupts and the LISP machine.
Part 5 - What next?
The following issues can be dealt with after this process above has been successfully completed:
- I/O interrupts, whether blocking or non-blocking
- Filesystems and virtual memory
That’s my plan for now. Getting all this working should allow the computer to boot into a LISP Machine, and be interactive through a keyboard and a serial terminal interface.
From there, I imagine the following can be done:
- the C libraries must be rewritten in a LISP. xj9 on here showed me some Schemes which can be statically compiled, that could be a good first step
- eventually the system can, after the C libraries needed to do file systems, virtual memory, networking and miscellaneous I/O, be developed interactively and internally using a REPL