shell/ is currently broken; we've overflowed available contiguous space for code. Block names based on https://www.compart.com/en/unicode/block: 0x0000 - 0x007f Basic Latin 128 0x0080 - 0x00ff Latin-1 Supplement 128 0x0100 - 0x017f Latin Extended-A 128 0x0180 - 0x024f Latin Extended-B 208 0x0250 - 0x02af IPA Extensions 96 0x02b0 - 0x02ff Spacing Modifier Letters 80 0x0300 - 0x036f Combining Diacritical Marks 112 0x0370 - 0x03ff Greek and Coptic 135 0x0400 - 0x04ff Cyrillic 256 0x0500 - 0x052f Cyrillic Supplement 48 0x0530 - 0x058f Armenian 91 0x0590 - 0x05ff Hebrew 88 0x0600 - 0x06ff Arabic 255 0x0700 - 0x074f Syriac 77 0x0750 - 0x077f Arabic Supplement 48 0x0780 - 0x07bf Thaana 50 0x07c0 - 0x07ff NKo 62 0x0800 - 0x083f Samaritan 61 0x0840 - 0x085f Mandaic 29 0x0860 - 0x086f Syriac Supplement 11 0x08a0 - 0x08ff Arabic Extended-A 84 0x0900 - 0x097f Devanagari 128 0x0980 - 0x09ff Bengali 96 0x0a00 - 0x0a7f Gurmukhi 80 0x0a80 - 0x0aff Gujarati 91 0x0b00 - 0x0b7f Oriya 91 0x0b80 - 0x0bff Tamil 72 0x0c00 - 0x0c7f Telugu 98 0x0c80 - 0x0cff Kannada 89 0x0d00 - 0x0d7f Malayalam 118 0x0d80 - 0x0dff Sinhala 91 0x0e00 - 0x0e7f Thai 87 0x0e80 - 0x0eff Lao 82 0x0f00 - 0x0fff Tibetan 211 0x1000 - 0x109f Myanmar 160 0x10a0 - 0x10ff Georgian 88 But don't trust the block sizes above. Thanks to gdb[1] for this helper: define z print 2 * (0x$arg1 - 0x$arg0 + 1) end e.g: (gdb) z 10a0 10ff 192 [1] https://sourceware.org/gdb/current/onlinedocs/gdb/Define.html |
||
---|---|---|
apps | ||
archive | ||
browse-slack | ||
editor | ||
html | ||
linux | ||
shell | ||
tools | ||
.gitattributes | ||
.gitignore | ||
101screen.subx | ||
102keyboard.subx | ||
103grapheme.subx | ||
104test.subx | ||
105string-equal.subx | ||
106stream.subx | ||
108write.subx | ||
109stream-equal.subx | ||
112read-byte.subx | ||
113write-stream.subx | ||
115write-byte.subx | ||
117write-int-hex.subx | ||
118parse-hex-int.subx | ||
120allocate.subx | ||
121new-stream.subx | ||
123slice.subx | ||
124next-token.subx | ||
126write-int-decimal.subx | ||
127next-word.subx | ||
301array-equal.subx | ||
302stack_allocate.subx | ||
308allocate-array.subx | ||
309stream.subx | ||
310copy-bytes.subx | ||
311decimal-int.subx | ||
312copy.subx | ||
313index-bounds-check.subx | ||
314divide.subx | ||
315stack-debug.subx | ||
316colors.subx | ||
317abort.subx | ||
318debug-counter.subx | ||
319timer.subx | ||
400.mu | ||
403unicode.mu | ||
408float.mu | ||
411string.mu | ||
412render-float-decimal.mu | ||
500fake-screen.mu | ||
501draw-text.mu | ||
502test.mu | ||
503manhattan-line.mu | ||
504test-screen.mu | ||
505colors.mu | ||
506math.mu | ||
507line.mu | ||
508circle.mu | ||
509bezier.mu | ||
510disk.mu | ||
511image.mu | ||
512array.mu | ||
513grapheme-stack.mu | ||
514gap-buffer.mu | ||
boot.subx | ||
cheatsheet.pdf | ||
font.subx | ||
help | ||
LICENSE.txt | ||
misc_checks | ||
misc_checks.subx | ||
modrm.pdf | ||
mu_instructions | ||
mu-init.subx | ||
mu.md | ||
README.md | ||
sib.pdf | ||
subx_bare.md | ||
subx_opcodes | ||
subx.md | ||
translate | ||
translate_emulated | ||
translate_subx | ||
translate_subx_emulated | ||
vimrc.vim | ||
vocabulary.md |
Mu: a human-scale computer
Mu is a minimal-dependency hobbyist computing stack (everything above the processor).
Mu is not designed to operate in large clusters providing services for millions of people. Mu is designed for you, to run one computer. (Or a few.) Running the code you want to run, and nothing else.
Here's the Mu computer running Conway's Game of Life.
git clone https://github.com/akkartik/mu
cd mu
./translate apps/life.mu # emit a bootable code.img
qemu-system-i386 code.img
![screenshot of Game of Life running on the Mu computer](/akkartik/mu/media/commit/1b18ec6ee960cb93f2f76d5cbaea8dc61a7339c4/html/life.png)
(Colorized sources. This is memory-safe code, and most statements map to a single instruction of machine code.)
Rather than start from some syntax and introduce layers of translation to implement it, Mu starts from the processor's instruction set and tries to get to some safe and clear syntax with as few layers of translation as possible. The emphasis is on internal consistency at any point in time rather than compatibility with the past. (More details.)
Tests are a key mechanism here for creating a computer that others can make their own. I want to encourage a style of active and interactive reading with Mu. If something doesn't make sense, try changing it and see what tests break. Any breaking change should cause a failure in some well-named test somewhere.
Currently Mu requires a 32-bit x86 processor.
Goals
In priority order:
- Reward curiosity.
- Easy to build, easy to run. Minimal dependencies, so that installation is always painless.
- All design decisions comprehensible to a single individual. (On demand.)
- All design decisions comprehensible without needing to talk to anyone. (I always love talking to you, but I try hard to make myself redundant.)
- A globally comprehensible codebase rather than locally clean code.
- Clear error messages over expressive syntax.
- Safe.
- Thorough test coverage. If you break something you should immediately see an error message. If you can manually test for something you should be able to write an automated test for it.
- Memory leaks over memory corruption.
- Teach the computer bottom-up.
Thorough test coverage in particular deserves some elaboration. It implies that any manual test should be easy to turn into a reproducible automated test. Mu has some unconventional methods for providing this guarantee. It exposes testable interfaces for hardware using dependency injection so that tests can run on -- and make assertions against -- fake hardware. It also performs automated white-box testing which enables robust tests for performance, concurrency, fault-tolerance, etc.
Non-goals
- Speed. Staying close to machine code should naturally keep Mu fast enough.
- Efficiency. Controlling the number of abstractions should naturally keep Mu using far less than the gigabytes of memory modern computers have.
- Portability. Mu will run on any computer as long as it's x86. I will enthusiastically contribute to support for other processors -- in separate forks. Readers shouldn't have to think about processors they don't have.
- Compatibility. The goal is to get off mainstream stacks, not to perpetuate them. Sometimes the right long-term solution is to bump the major version number.
- Syntax. Mu code is meant to be comprehended by running, not just reading. For now it's a thin memory-safe veneer over machine code. I'm working on a high-level "shell" for the Mu computer.
Toolchain
The Mu stack consists of:
- the Mu type-safe and memory-safe language;
- SubX, an unsafe notation for a subset of x86 machine code; and
- bare SubX, a more rudimentary form of SubX without certain syntax sugar.
All Mu programs get translated through these layers into tiny zero-dependency binaries that run natively. The translators for most levels are built out of lower levels. The translator from Mu to SubX is written in SubX, and the translator from SubX to bare SubX is built in bare SubX. There is also an emulator for Mu's supported subset of x86, that's useful for debugging SubX programs.
Mu programs build natively either on Linux or on Windows using WSL 2. For Macs and other Unix-like systems, use the (much slower) emulator:
./translate_emulated apps/ex2.mu # ~2 mins to emit code.img
Mu programs can be written for two very different environments:
-
At the top-level, Mu programs emit a bootable image that runs without an OS (under emulation; I haven't tested on native hardware yet). There's rudimentary support for some core peripherals: a 1024x768 screen, a keyboard with some key-combinations, a PS/2 mouse that must be polled, a slow ATA disk drive. No hardware acceleration, no virtual memory, no process separation, no multi-tasking, no network. Boot always runs all tests, and only gets to
main
if all tests pass. -
The top-level is built using tools created under the
linux/
sub-directory. This sub-directory contains an entirely separate set of libraries intended for building programs that run with just a Linux kernel, reading from stdin and writing to stdout. The Mu compiler is such a program, atlinux/mu.subx
. Individual programs typically run tests if given a command-line argument calledtest
.
The largest program built in Mu today is its prototyping environment for writing slow, interpreted programs in a Lisp-based high-level language.
![screenshot of the Mu shell](/akkartik/mu/media/commit/1b18ec6ee960cb93f2f76d5cbaea8dc61a7339c4/html/20210624-shell.png)
(For more details, see the shell/
directory.)
While I currently focus on programs without an OS, the linux/
sub-directory
is fairly ergonomic. There's a couple of dozen example programs to try out
there. It is likely to be the option for a network stack in the foreseeable
future; I have no idea how to interact on the network without Linux.
Syntax
The entire stack shares certain properties and conventions. Programs consist
of functions and functions consist of statements, each performing a single
operation. Operands to statements are always variables or constants. You can't
perform a + b*c
in a single statement; you have to break it up into two.
Variables can live in memory or in registers. Registers must be explicitly
specified. There are some shared lexical rules. Comments always start with
'#'. Numbers are always written in hex. Many terms can have context-dependent
metadata attached after '/'.
Here's an example program in Mu:
![ex2.mu](/akkartik/mu/media/commit/1b18ec6ee960cb93f2f76d5cbaea8dc61a7339c4/html/ex2.mu.png)
More resources on Mu:
-
Library reference. Mu programs can transparently call low-level functions written in SubX.
Here's an example program in SubX:
== code
Entry:
# ebx = 1
bb/copy-to-ebx 1/imm32
# increment ebx
43/increment-ebx
# exit(ebx)
e8/call syscall_exit/disp32
More resources on SubX:
-
Some starter exercises for learning SubX (labelled
hello
). Feel free to ping me with any questions. -
The list of x86 opcodes supported in SubX:
linux/bootstrap/bootstrap help opcodes
.
Forks
Forks of Mu are encouraged. If you don't like something about this repo, feel free to make a fork. If you show it to me, I'll link to it here. I might even pull features upstream!
- uCISC: a 16-bit processor being designed from scratch by Robert Butler and programmed with a SubX-like syntax.
- subv: experimental SubX-like syntax by s-ol bekic for the RISC-V instruction set.
- mu-x86_64: experimental fork for 64-bit x86 in collaboration with Max Bernstein. It's brought up a few concrete open problems that I don't have good solutions for yet.
- mu-normie: with a more standard
build system for the
linux/bootstrap/
directory that organizes the repo by header files and compilation units. Stays in sync with this repo.
Desiderata
If you're still reading, here are some more things to check out:
-
How to get your text editor set up for Mu and SubX programs.
-
A summary of how the Mu compiler translates statements to SubX. Most Mu statements map to a single x86 instruction. (colorized version)
-
A prototype live-updating programming environment for a postfix language that I might work on again one day:
cd linux ./translate tile/*.mu ./a.elf screen
Credits
Mu builds on many ideas that have come before, especially:
- Peter Naur for articulating the paramount problem of programming: communicating a codebase to others;
- Christopher Alexander and Richard Gabriel for the intellectual tools for reasoning about the higher order design of a codebase;
- David Parnas and others for highlighting the value of separating concerns and stepwise refinement;
- The folklore of debugging by print and the trace facility in many Lisp systems;
- Automated tests for showing the value of developing programs inside an elaborate harness;
On a more tactical level, this project has made progress in a series of bursts as I discovered the following resources. In autobiographical order, with no claims of completeness:
- “Bootstrapping a compiler from nothing” by Edmund Grumley-Evans.
- StoneKnifeForth by Kragen Sitaker, including a tiny sketch of an ELF loader.
- “Creating tiny ELF executables” by Brian Raiter.
- Single-page cheatsheet for the x86 ISA by Daniel Plohmann (cached local copy)
- Minimal Linux Live for teaching how to create a bootable disk image using the syslinux bootloader.
- “Writing a bootloader from scratch” by Nick Blundell.
- Wikipedia on BIOS interfaces: Int 10h, Int 13h.
- Some tips on programming bootloaders by Michael Petch.
- xv6, the port of Unix Version 6 to x86 processors
- Some tips on handling keyboard interrupts by Alex Dzyoba and Michael Petch.