Split the machine from its front end, and add Voyager
The Segan Voyager is the same SplitBit with a screen and a speaker instead of a terminal, and this is the rung that makes there be two of them at all. Everything that is actually the machine - the CPU, the controller, the devices, the run loop, the reporting - moves to machine.c, and each front end brings one file of its own. emulator.c is now sixty lines of argument handling and a three line loop. The machine runs in SLICES rather than to completion, because that is the cut a window needs: run a slice, present a frame, run another. A terminal runs slices until the machine stops. Both loops are three lines, which is why the cut is there rather than anywhere else. At this stage Voyager's window is empty. There is no video device yet and inventing a temporary way to draw would mean building something to throw away. PLAIN MAKE STILL WORKS WITH NO GRAPHICS LIBRARY. Raylib is probed by compiling and linking against it rather than by looking for a file, because a header with no library behind it passes a file check and then fails at link time. Where it is missing, make says so once and builds everything else - the machine, the assembler, the disk tool, the linter and the whole suite. A project about a small understandable CPU should not need OpenGL to run its tests. That nearly broke here: make strict globs Source/Emulator/*.c, so it would have tried to compile voyager.c and failed on precisely the machines the split exists to support, and this machine has Raylib so nothing would have caught it. Tests/voyager.sh runs the WHOLE MANIFEST through Voyager and holds it to the recorded results SplitBit is held to. Not that the two look alike: that one satisfies every recording the other does, byte for byte, exit status included. It reuses run.sh, which now takes the machine from SPLITBIT_EMULATOR, rather than keeping a second copy of the runner that would drift. Voyager not being built is not a failure - it says so and passes. Verified both ways. Made Voyager print one extra line, and 114 of 165 failed: exactly the tests that run the emulator, with the 51 assemble-only and xfail cases correctly untouched. Removed the binary, and the script skipped. Built with HAVE_RAYLIB=no, and everything else still built and checked clean. --headless is taken out of the arguments in voyager.c rather than in the shared parser, which should not learn about a window only one binary has. It exists so the suite can run this binary at all: a front end that could only be exercised by a person looking at it would be a front end nothing checks. loadFile takes a const char * now, which it always should have. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW
This commit is contained in:
co-authored by
Claude Opus 5
parent
4c3eac8d9c
commit
e3ef25e3b3
+27
-9
@@ -9,7 +9,7 @@ believe them.
|
||||
|
||||
## What The Suite Claims:
|
||||
|
||||
The suite is not one thing. It is eight scripts making five different kinds of claim, and
|
||||
The suite is not one thing. It is nine scripts making five different kinds of claim, and
|
||||
knowing which claim you are relying on is the whole point of this document. A recorded
|
||||
transcript and a byte-for-byte comparison against a second implementation both print
|
||||
`[ok ]`, and they are worth wildly different amounts.
|
||||
@@ -37,8 +37,8 @@ Everything in between is somewhere on that line.
|
||||
make test
|
||||
```
|
||||
|
||||
Builds the four tools, checks they compile under strict ISO C, and runs the scripts in
|
||||
order. Takes a few seconds. Everything must pass; there are no expected failures at the
|
||||
Builds the four tools - and Voyager, where Raylib is installed - checks they compile under
|
||||
strict ISO C, and runs the scripts in order. Takes a few seconds. Everything must pass; there are no expected failures at the
|
||||
level of the suite, only tests that record an expected failure of the assembler.
|
||||
|
||||
```
|
||||
@@ -54,6 +54,7 @@ Individual scripts can be run on their own, from anywhere:
|
||||
./Tests/run.sh Every program in the manifest.
|
||||
./Tests/run.sh hello waitTest Only the named ones.
|
||||
./Tests/run.sh --bless Record current output as expected. See below.
|
||||
./Tests/voyager.sh The same manifest, through the other front end.
|
||||
./Tests/disk.sh The disk tool against the format.
|
||||
./Tests/cycles.sh What the memory controller charges.
|
||||
./Tests/terminal.sh The things a recorded file cannot see.
|
||||
@@ -91,8 +92,8 @@ without anybody meaning it to.
|
||||
|
||||
### 2. A second implementation
|
||||
|
||||
`Tests/native.sh` and `Tests/agree.sh` are the two checks that do not compare the code
|
||||
against a memory of itself.
|
||||
`Tests/native.sh`, `Tests/agree.sh` and `Tests/voyager.sh` are the checks that do not
|
||||
compare the code against a memory of itself.
|
||||
|
||||
`native.sh` assembles the same source with the host assembler and with `Asm.sbx` running on
|
||||
the emulated machine, and compares the two binaries byte for byte. **The only honest test of
|
||||
@@ -109,10 +110,27 @@ block, what a directory's unused fields hold, the version in the superblock, the
|
||||
count. A disagreement in any of those is a disk one of them can read and the other cannot,
|
||||
and the usual way that gets discovered is somebody's file coming back wrong months later.
|
||||
|
||||
Both scripts depend on both sides being driven in the same order, because both allocate
|
||||
first fit and both take the first free entry. Given the same operations in the same
|
||||
sequence they should reach the same bytes, and any difference is real rather than an
|
||||
artefact of the script.
|
||||
`native.sh` and `agree.sh` both depend on the two sides being driven in the same order,
|
||||
because both allocate first fit and both take the first free entry. Given the same
|
||||
operations in the same sequence they should reach the same bytes, and any difference is real
|
||||
rather than an artefact of the script.
|
||||
|
||||
`Tests/voyager.sh` is the cheapest of the three, because it reuses the runner rather than
|
||||
repeating it. SplitBit and Voyager share every line of the machine and differ only in what
|
||||
they present - a terminal, or a window and a speaker - and the way to keep that true is to
|
||||
make the claim testable. So it runs the **whole manifest** through Voyager with
|
||||
`--headless`, held to the same recorded results SplitBit is held to. The claim is not that
|
||||
the two look alike: it is that one satisfies every recording the other does, byte for byte,
|
||||
exit status included.
|
||||
|
||||
`Tests/run.sh` takes the machine to run from `SPLITBIT_EMULATOR`, which is what makes that
|
||||
possible without a second copy of the runner. A copy would drift, and the first thing to go
|
||||
would be whichever awkward case got added to only one of them.
|
||||
|
||||
**Voyager not being built is not a failure.** It needs Raylib and nothing else here does,
|
||||
which is the whole point of there being two binaries; a suite that failed on a machine with
|
||||
no graphics library would be enforcing exactly the dependency the split exists to avoid. The
|
||||
script says it was skipped, and passes.
|
||||
|
||||
### 3. Named properties
|
||||
|
||||
|
||||
Reference in New Issue
Block a user