Dogfooding #2: A Chain of Tools, Each Testing the One Below

Each of my COR24 tools is tested by the one built on it. The simple assembler was dogfooded by my C compiler, which was dogfooded by the PL/SW compiler written in C. Now I am porting PL/SW from C to HLASM, my macro assembler written in COR24 assembly, and porting the tiny-C demos to HLASM first to prove the method. It already found a bug: HLASM's structured IF and DO had never produced code the assembler would accept, and text-only regression tests never noticed. The plan ends with HLASM and PL/SW each compiling themselves, and the SWTOS microkernel as the test of both.

The first Dogfooding post was about one tool finding the limits of another: a Pascal VM’s allocator, outgrown by an OCaml written in Pascal. This one is about a whole chain of them. On COR24, each of my tools is tested by the one built on top of it, and I am rebuilding the chain so that, in the end, the top two test themselves.

Resource	Link
HLASM	sw-cor24-hlasm, its bootstrap plan
PL/SW	sw-cor24-plsw, its C to HLASM plan
tiny C	sw-cor24-x-tinyc (`tc24r`)
The assembler	sw-cor24-x-assembler (`cor24-asm`)
SWTOS	sw-tos
Background	Why I Use #3: Assembler, C and PL/SW
The series	Dogfooding: every post
Comments	Discord

The chain as it stands

Why I Use #3 described the three languages I write COR24 code in. Built one on another, they test each other:

The simple assembler, cor24-asm, turns COR24 assembly text into bytes. Everything above it depends on it.
My C compiler, tc24r, emits assembly for cor24-asm, so every C program it compiles dogfoods the assembler.
The PL/SW compiler is written in C. Compiling it with tc24r dogfooded the C compiler, a real program of thousands of lines rather than a demo.
SWTOS, my microkernel, is written in assembler and some PL/SW, so it dogfoods the assembler and part of PL/SW.

That chain has a host-side compiler in the middle: tc24r runs on the host, not on COR24.

Moving PL/SW onto HLASM

HLASM is my macro assembler for COR24, inspired by IBM’s High Level Assembler: structured IF, DO and SELECT, macros with parameters, conditional assembly. It is written in COR24 assembly, runs on COR24, and writes plain assembly text for cor24-asm. So today HLASM dogfoods the simple assembler.

The plan for PL/SW, written this week, is to port its compiler from C to HLASM:

hlasm.s (hand-written COR24 assembly)
   -> assembles PL/SW written in HLASM
      -> compiles PL/SW written in PL/SW
         -> compiles itself

That takes the host C compiler out of the chain: every stage after hlasm.s is built on COR24. The port is mechanical, each C function becoming one HLASM routine with the same calling convention, so it can be checked against tc24r’s output a function at a time. And PL/SW, a real compiler, becomes the program that dogfoods HLASM.

The tiny-C demos go first

Before porting a compiler, the method has to work on something smaller. HLASM’s current saga ports the tiny-C demos, the example programs that ship with tc24r, from C to HLASM, building a shared library of macros (routine entry and exit, calls, UART output, data) as it goes. Its steps: make structured control flow assemble, audit HLASM’s limits, add an end-to-end harness that runs HLASM, assembles its output and runs the result, survey the demos for recurring idioms, build the macro library, port the demos, and show C, tc24r’s assembly and HLASM side by side.

What dogfooding found on day one

The first step had to fix something that had been wrong all along. HLASM lowered its structured IF, DO and SELECT into jumps written jmp <label>. But COR24’s jmp takes only a register, jmp (r0), and cor24-asm rejects jmp <label>, as it always had. HLASM’s regression tests compared the assembly text it wrote and never assembled it, so nothing noticed. Nine demos used the broken form.

It took a program that had to run, not just print, to find it. HLASM now sizes each jump in a first pass and emits a short bra when the target is in range, or saves a register around a long la/jmp when it is not (the design). That is the whole argument for dogfooding in one bug: a test that checks the text a tool writes is not the same as a test that runs what it wrote.

Where it is headed

Three logos: the word HLASM in blue horizontal stripes; the PL/SW shield, PL in orange and SW in light blue; and the SWTOS badge, a chip reading Software Wrighter Tiny O/S

Two loops close at the top of the chain:

HLASM in HLASM. The bootstrap plan starts small: the hand-written hlasm.s assembles a reduced HLASM written in the subset it already supports, and the full one grows from there. Then HLASM dogfoods itself.
PL/SW in PL/SW. Once PL/SW is written in HLASM, the next stage is a PL/SW compiler written in PL/SW, compiling itself.

And SWTOS, which today dogfoods the simple assembler and some PL/SW, is the test I want for both: an operating system built with the refactored HLASM and PL/SW, in place of cor24-asm. A microkernel that boots and runs is a harder test than any demo.