Three papercuts a visitor would hit first

Found by a review, all three confirmed by trying them rather than by
reading.

1. THE STRICT BUILD CLAIM WAS FALSE. The README says the sources build clean
   under -std=c11 -pedantic with -Wall -Wextra, and they did not: realpath is
   an XSI interface, and _POSIX_C_SOURCE=200809L does not reach it, so the
   assembler would not compile. The ordinary -Os build never saw it, because
   without -std=c11 the compiler's own default declares realpath anyway.

   _XOPEN_SOURCE=700 is POSIX.1-2008 plus XSI, and covers every file on its
   own. Narrowed by compiling each source with each candidate macro rather
   than by adding one and hoping.

   And 'make strict' now checks it, as part of 'make test'. The README makes
   a claim somebody may check by typing it, so the suite types it. Verified
   the check bites by putting the old macro back.

2. THE COSMOS README HAD NOT CAUGHT UP WITH THIS WEEK. It said there were no
   breakpoints and proposed writing a spare byte over an instruction - two
   commits after SWI osBreak was built, which does it without overwriting
   anything and is described correctly further down the same file. Its
   Current Scope said there was no native assembler and that self-hosting
   was the intended long-term milestone. And the streaming section spoke of
   a machine "one day going to assemble itself".

   All three now say what is true. Self-hosting is described as done, with
   what is left of it named: a linker, and an editor that knows what
   assembly is.

3. 'make run-hello' DID NOT WORK, and it is the one command the makefile's
   own header advertises. It was a pattern rule against $(BUILD)/%.bin,
   which worked while every program sat at the top of Programs/ and broke
   the moment they were filed into Examples/ - which I did, four commits ago,
   without trying it.

   The name is looked up among the programs now, so it is the program's name
   rather than its path, and an unknown one lists what there is instead of
   saying "No rule to make target".

The same sweep was run across all four documents for other claims this week
invalidated. The remaining "not yet" phrases are about faults that genuinely
are not defined yet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW
This commit is contained in:
Anachronaut
2026-08-21 16:17:24 -04:00
co-authored by Claude Opus 5
parent 7e8639489b
commit 3f95056eec
3 changed files with 49 additions and 12 deletions
+11 -8
View File
@@ -223,7 +223,7 @@ HI
Typed in as bytes, checked by disassembling it back, and run. It ends with `SWI osExit`, which is how it gives the machine to the shell rather than to nothing.
There are no breakpoints yet, and `g` does not come back. The machinery for both already exists and nothing has used it: SplitBit has 192 undecodable bytes, and an invalid opcode dispatches through the `BadOpcode` vector carrying **the address of the offending byte**. A breakpoint is a spare byte written over an instruction and a handler waiting for it.
`g` does not come back: what it runs has to give the machine to the shell itself, which `SWI osExit` is how a program does. Breakpoints are not the monitor's - they are `SWI osBreak`, written into the program rather than poked over it, and described under Stopping To Look.
### The Editor:
@@ -354,7 +354,7 @@ A file of 256 blocks or more is refused by `osFileRead` rather than partly read,
### Reading A File That Will Not Fit:
`osFileRead` hands over a whole file, which settles the question for anything under 64K and settles nothing above it. CosmOS's own source is above it: the sources together are a hundred kilobytes and Data Memory is sixty four. A machine that is one day going to assemble itself has to be able to read a file bigger than its memory.
`osFileRead` hands over a whole file, which settles the question for anything under 64K and settles nothing above it. CosmOS's own source is above it: the sources together are a hundred kilobytes and Data Memory is sixty four. A machine that assembles itself has to be able to read a file bigger than its memory, and this is what that stands on.
So there is a second way to ask. `osFileInfo` says how big something is and `osFileBlock` hands over one block of it, and between them a program reads a file of any size through a buffer of 256 bytes.
@@ -552,13 +552,16 @@ than merely checking its filesystem code against itself.
CosmOS is early software for an experimental computer. It runs one application at a
time, has no privilege levels or process isolation, does not relocate applications, and
provides a line assembler but not yet a native assembler for source files, nor a linker. Its present purpose is to make
SplitBit usable from inside the machine: inspect it, manage persistent files, load
programs, provide common services, and return reliably to a command prompt.
has no linker. Its purpose is to make SplitBit usable from inside the machine: inspect
it, manage persistent files, load programs, provide common services, and return reliably
to a command prompt.
The intended long-term milestone is self-hosting: editing SplitBit assembly source under
CosmOS, assembling and linking it natively, and eventually rebuilding CosmOS and its own
development tools on the machine.
**Self-hosting is done.** `Assembler/` reads source off a SplitBit disk and writes a boot
image or a loadable program back to it, byte for byte what the host assembler builds from
the same source. It assembles CosmOS, and it assembles itself, and the CosmOS it built
assembles CosmOS again to the same bytes. What is left of that milestone is a linker, and
editing source under CosmOS comfortably enough to want to: `Edit` is line oriented and
knows nothing about assembly.
## Additional Information: