sectorlisp: a 512-byte LISP that boots from BIOS and evaluates itself

Three implementations of the same idea

sectorlisp is a 512-byte implementation of LISP that is able to bootstrap John McCarthy's meta-circular evaluator on bare metal.

The project lays out three deliverables, and the numbering in the README has a small quirk because the list is numbered one, two, two.

The first is a LISP implementation written in LISP, as a single pure expression, using only the essential functions of the language. It lives in `lisp.lisp`, and the README describes it as the same meta-circular evaluator from John McCarthy's 1960s paper, except with its bugs fixed, dependencies included and syntactic sugar removed.

The second is a readable, portable C reference implementation, in `lisp.c`, which shows how the meta-circular evaluator can be natively bootstrapped on POSIX conforming platforms, with a pleasant readline-like interface.

The third is a 512-byte i8086 implementation of LISP that boots from BIOS on personal computers, in `sectorlisp.S`, and the README claims it is, to the best of the authors' knowledge, the tiniest true LISP implementation to date.

That structure is the real design. The C version is the readable one you would actually read to understand the evaluator, the LISP version is the one you can paste into any LISP REPL, and the boot sector is the one that proves the whole thing fits in a sector. The repository also carries a footprint comparison image at `bin/footprint.png`.

The licence is ISC, the primary language is C, the default branch is main, and the last push was on 2026-06-14. There are no GitHub releases, so there is no version history to consult.

Stripping LISP back to its essential functions

The motivation is stated in the overview. LISP has been described as the Maxwell's equations of software, and the project's complaint is that very little effort has gone into reducing those equations to their simplest possible form. Even the original LISP paper from the 1960s defines LISP with nonessential elements, with `LABEL` given as the example.

That is the project thesis, and it explains the choices in the implementation. If the goal is the smallest possible true LISP, then a language with a `LABEL` construct is already too large, and each function you keep has to earn its place.

The meta-circular evaluator is the mechanism for doing that reduction rather than arguing about it. A meta-circular evaluator is a program written in a language that interprets that same language. The 1960s paper is the original, and the README is explicit that this version has the bugs fixed, the dependencies included and the syntactic sugar removed. Including the dependencies matters for a self-contained artefact, because a self-hosting evaluator that needs a function it does not define cannot bootstrap in a bare sector.

The README also links the essay about LISP as the Maxwell's equations of software and the original paper, so the argument and the reference implementation are both a click away for anyone who wants to check the reasoning against the source.

The build is an assembler, a linker script and objcopy

The Makefile is small enough to read in one go, and it is where the 512 bytes are accounted for.

The C flags are `-std=gnu89 -w -O`, so the C reference implementation is compiled as GNU89 with warnings off and optimisation on. The `all` target builds three things: the `lisp` binary, `bin/sectorlisp.bin` and `bin/sectorlisp.bin.dbg`.

The C binary links `lisp.o` with `bestline.o`, and `bestline.c` and `bestline.h` at the root are the readline-like interface. That is a separate piece of code compiled into the C binary, so the build needs nothing beyond the repository.

The boot sector is a different pipeline entirely. `sectorlisp.S` is assembled with `$(AS) -g -o $@ $<` into `bin/sectorlisp.o`, the debug variant `bin/sectorlisp.bin.dbg` is produced by linking with `$(LD) -T sectorlisp.lds -o $@ $<` using the linker script `sectorlisp.lds`, and the final `bin/sectorlisp.bin` is extracted with `objcopy -S -O binary $< $@`.

That last step is the classic trick for producing a flat binary image, and keeping the debug variant alongside it is a detail worth noticing. The debug image keeps the symbols and the section layout, so you can disassemble it and see what the 512 bytes actually are, while the stripped image is what you write to a disk. A 512-byte program that claims to be a LISP is not much fun to debug from raw bytes, so the two artefacts together are what make the project legible.

The `clean` target removes the binaries and object files, and the Makefile is written in the older BSD make style with the `.PHONY` declarations and backslash continuations.

Running it: a floppy disk, an emulator or QEMU

The getting started section is short. For the C implementation:

$ make
$ ./lisp

For the boot sector, the README says that after running `make` you should see a `sectorlisp.bin` file, which is a master boot record you can put on a floppy disk and boot from BIOS.

That floppy disk is the interesting constraint. This is a boot sector, so the delivery mechanism is a 512-byte image on a bootable device, and most people do not have one any more. The README therefore recommends an emulator, and names Das Blinkenlights:

curl --compressed https://justine.lol/blinkenlights/blinkenlights-latest.com >blinkenlights.com
chmod +x blinkenlights.com
./blinkenlights.com -rt sectorlisp.bin

The fact that the recommended emulator needs to be downloaded as a single executable file and made executable is itself a small usability wrinkle in a project that prides itself on minimalism.

QEMU is offered as the alternative:

qemu-system-i386 -nographic -fda sectorlisp.bin

The `-nographic` flag is what makes the serial console visible, and `-fda` attaches the image as a floppy disk. So the two supported routes are a tiny purpose-built emulator and a general virtual machine, and the second one is the one most people already have.

The README also points to a wiki for further information, and the demo section links a video showing the boot in the blinkenlights emulator, the bootstrap of the meta-circular evaluator, and the evaluation of a program for finding the first element in a tree.

Where sectorlisp is the wrong tool

The first wrong case is any use of this as a LISP implementation rather than as a study. The whole point is that only the essential functions are present, and a language defined by what it omits is not a language you would run anything on. There is no package ecosystem, no numeric tower, no string library, no error handling conventions, and a 512-byte sector has no room for any of them.

The second wrong case is a project that needs a real embedded scripting layer. sectorlisp is a demonstration that a meta-circular evaluator fits in a boot sector, not a scripting engine for firmware. The C implementation is a reference for reading, not a component to embed.

The third wrong case is a team that cannot run 16-bit real mode code. The boot sector is i8086, the C version is POSIX, and the two are separate programs. A macOS laptop with a modern kernel will not run the sectorlisp binary, and the C implementation on a modern POSIX system is a teaching artefact rather than something to build on.

The fourth is a project that needs the self-hosting property but with a modern language. The idea of bootstrapping a meta-circular evaluator is a research and pedagogy exercise, and the interesting versions of it today are in the literature rather than in a boot sector. If your goal is to understand metacircularity, reading `lisp.lisp` and McCarthy's paper side by side is the path, and the boot sector is a flourish on top of it.

What sectorlisp gives you for that goal is rare. A self-hosting evaluator that fits in a single sector, with a readable C reference to check the assembly against, is a genuinely good artefact, and the fact that it runs on bare metal without an operating system is a demonstration of something most explanations of LISP cannot make.

Editorial conclusion

sectorlisp suits someone who wants to understand what a minimal LISP actually costs in bytes, and who is prepared to read 512 bytes of assembly and a meta-circular evaluator to find out, or to use the LISP-in-LISP expression as a teaching artefact. It does not suit a production system, a general-purpose scripting language, or a project that needs a package ecosystem, a garbage collector or a numeric tower. Before trying it, build the C implementation with `make` and the boot sector with the assembler and linker script, and if you want to watch the self-hosting happen rather than take it on faith, use Das Blinkenlights or QEMU as the README describes, since a floppy disk is not an option most people have any more.

Frequently asked questions

Official sources

1. Issues
2. jart/sectorlisp on GitHub
3. License: ISC
4. README