Tested by inserting a call into the shell, but we can't leave it in because
every test ends up clobbering the disk. So it's now time to think about
a testable interface for the disk.
Baremetal is now the default build target and therefore has its sources
at the top-level. Baremetal programs build using the phase-2 Mu toolchain
that requires a Linux kernel. This phase-2 codebase which used to be at
the top-level is now under the linux/ directory. Finally, the phase-2 toolchain,
while self-hosting, has a way to bootstrap from a C implementation, which
is now stored in linux/bootstrap. The bootstrap C implementation uses some
literate programming tools that are now in linux/bootstrap/tools.
So the whole thing has gotten inverted. Each directory should build one
artifact and include the main sources (along with standard library). Tools
used for building it are relegated to sub-directories, even though those
tools are often useful in their own right, and have had lots of interesting
programs written using them.
A couple of things have gotten dropped in this process:
- I had old ways to run on just a Linux kernel, or with a Soso kernel.
No more.
- I had some old tooling for running a single test at the cursor. I haven't
used that lately. Maybe I'll bring it back one day.
The reorg isn't done yet. Still to do:
- redo documentation everywhere. All the README files, all other markdown,
particularly vocabulary.md.
- clean up how-to-run comments at the start of programs everywhere
- rethink what to do with the html/ directory. Do we even want to keep
supporting it?
In spite of these shortcomings, all the scripts at the top-level, linux/
and linux/bootstrap are working. The names of the scripts also feel reasonable.
This is a good milestone to take stock at.
I've found two bugs in SubX libraries:
1. next-word had an out-of-bounds read
2. next-word was skipping comments, because that's what I need during bootstrapping.
I've created a new variant called next-raw-word that doesn't skip comments.
These really need better names.
We're now at the point where 4b.mu has the right structure and returns
identical result to 4a.mu.
I've wrestled for a long time with how to support integer division with
its hard-coded registers. The answer's always been staring me in the face:
just turn it into a function! We already expect function outputs to go
to hard-coded registers.
Both manual tests described in commit 7222 now work.
To make them work I had to figure out how to copy a file. It
requires a dependency on a new syscall: lseek.
So far I've been assuming that read-key only works for ascii, and that
I'd need to get more sophisticated both for multi-byte utf-8 and multi-byte
terminal escape codes like arrow keys. Rather to my surprise, both work
fine. We just need to adjust the types to reflect this fact.
tile is already visibly slow (49x212 screen) :/ So programmer needs more
control over performance.
But this may not be the right approach. That extra flush-stdout in tui.mu
suggests it's either going to be finicky, or we have to flush on every
attribute change. And going through a buffered-file may be slower. May.
No support for combining characters. Graphemes are currently just utf-8
encodings of a single Unicode code-point. No support for code-points that
require more than 32 bits in utf-8.
Both have the same size: 4 bytes.
So far I've just renamed print-byte to print-grapheme, but it still behaves
the same.
I'm going to support printing code-points next, but grapheme 'clusters'
spanning multiple code-points won't be supported for some time.
We now have all existing apps and prototypes going through the dependency-injected
wrapper, even though it doesn't actually implement the fake screen yet.