The devlog is a collection of design notes.
Below are disjointed thoughts on the creation of a clean-slate computing stack based on the universal virtual machine strategy for digital preservation. As opposed to the seemingly natural trend in software, Uxn is making itself available on platforms increasingly further backward in time, growing increasingly smaller.
- Part 1: A virtual machine
- Part 2: A personal computer
- Part 3: A programming language
The content of the devlog was presented as a talk at Handmade Seattle 2022, watch the full presentation: Weathering Software Winter.
Acknowledgments
The realization of this project is largely due to the work of the community, with special thanks to Andy Alderwick, Sigrid Solveig Haflínudóttir, Andrew Richards, and everyone else who contributed ideas and shared their knowledge with me, without whom Uxn could not have become what it is now. Nearly a year after its initial draft, a lot of uxn code has been written. In fact, this text has been written in Left, a text-editor hosted on this strangely personal computer, and this wiki was also generated by it.
A virtual machine
Before we begin,
Emulation is the reproduction of the behavior of a computer's physical circuitry with software. Given that an emulator can translate the actions of one computer onto an other, the same program could be used on both. This is emulation.
Someone could devise the actions of a fictional computer that is not necessarily based on existing hardware, write software for this fantastical computer, implement an emulator for it, and use the same program on any supported computer. This is a virtual machine.
Over the years, I wrote software for various frameworks and peripherals. Most have died with their respective platform, the rest have fallen behind their ever-changing toolchain. Bitrot is the inability to access digital data because hardware and software no longer exist to read its format. Perhaps it's just a matter of time until people build emulators to make these projects usable again, otherwise these projects were never truly mine, and my learning of these languages only ever belonged to the platforms.
So, why not C? While terminal utilities can be made portable, cross-platform audio and graphical development is not.
I. An Adequate Number Of Bits
During my research into portability, I kept thinking about how frictionless it is to play NES games today. Pulling on that thread led me to projects designed explicitly for virtual machines, such as Another World which is equally easy to play today due to its targeting of a portable virtual machine, instead of any ever-changing physical hardware.
For a time, I thought I ought to be building software for the NES to ensure their survival over the influx of disposable modern platforms — So, I did. Sadly, most of the software that I care to write and use require slightly more than an 8-button controller.
So, why not the Commodore 64? While it is of the same era as the NES, not only is implementing a 6502 emulation not an simple task, implementing a c64 emulator is a monumental project.
II. Tarpits & Houses Of Cards
If the focus of this experiment is to ensure the support of a piece of code by writing emulation software for each new platform, the specifications should be painless to implement. Let's use the time one would need to write a passable emulator as a limit in complexity for this system. Could a computer science student implement a mediocre emulation of the 6502 instructions in an afternoon? Could that design be simplified, changed in some way to make it more approachable for would-be implementers?
Subleq is a One-Instruction architecture, an emulator for this platform takes at most 15 minutes to write. Perhaps this could be an interesting target, but what it does away in emulation complexity, it offloads onto the toolchain needed to make intelligible programs.
So, let us also set a limit to the complexity of the toolchain as to not find ourselves in a tarpit. It would be an equally Herculean task to build an emulator and assembler for a machine with thousands of instructions; or a single instruction machine building abstract logic from thousands of primitive parts. How complex can an assembler be if the maximum amount of time one could use to write it is a single weekend, or at most 500 lines.
LIT ~ [PC]
JCI ~ (c8){PC+=[PC]}
JMI ~ {PC+=[PC]}
JSI ~ {R.PC PC+=[PC]}
BRK ~ EQU a b==c LDZ a b [c8] ADD a b+c
INC a b c+1 NEQ a b!=c STZ a {[c8]=b} SUB a b-c
POP a b GTH a b>c LDR a b [PC+c8] MUL a b*c
NIP a c LTH a b<c STR a {[PC+c8]=b} DIV a b/c
SWP a c b JMP a b {PC+=c} LDA a b [c16] AND a b&c
ROT b c a JCN a (b8){PC+=c} STA a {[c16]=b} ORA a b|c
DUP a b c c JSR a b {R.PC PC+=c} DEI a b {[D+c8]} EOR a b^c
OVR a b c b STH a b {R.c} DEO a {[D+c8]=b} SFT a b>>c8l<<c8h
We shall call this definition of a computer that fits on a napkin, capable of self-hosting in a few hundred lines of its own assembly — A One-page Computer.
III. Things Betwixt
A paper computer was created in the early 1980s, when computer access was not yet widespread, it consists of a piece of paper with 21 lines of code on the left and eight registers on the right. The instruction set of five commands(inc, dec, jmp, isz, stp) is small but Turing complete, meaning that it can approximately simulate the computational aspects of any other real-world general-purpose computer, and is therefore enough to represent all mathematical functions.
In 1977, a programmer wrote a small virtual machine with 36 instructions, 16 registers and 4096 bytes of memory. It has no mouse, the screen is barely capable of displaying readable text, its controller is a nightmare. — But I was able to write an emulator and an assembler for it, in an afternoon.
There is a type of electronics relevant to emulation that has no chips, no instruction set, but instead the programmer designs the hardware circuit in software. As much fun as it would be to create a design that maps well onto these machines, it would make for a poor emulation on my existing devices as it would use nearly none of the optimizations available on the host computer.
Somewhere along this voyage into finding a suitable host for my programs, I began thinking about electronic waste, and I couldn't justify surrounding myself with yet more electronics. This dream platform would therefore be designed to be emulated, its complexity would be designed around the complexity of software and not that of hardware.
IV. Back & Forth
The balancing act of virtual machine instructions, assembler, emulator and the resulting capabilities of its language revealed the stack machines as ideal systems.
Forth is a programming language that consists simply of splitting text into a list of words, breaking on whitespace, and to interpret each word, words are often combinations of other words combined to create more complex words.
Brackets and parentheses are unnecessary: the program merely performs calculations in the order that is required, letting the automatic stack store intermediate results on the fly for later use. Likewise, there is no requirement for precedence rules.
In Forth, memory is made of cells, which are typically 16-bits in length, meaning that each piece of data is a number from 0 to 65535. For this specific imaginary system, I wanted the memory to consist of cells of 8-bit, or numbers from 0 to 255. For example, the 12 / (34 - 12) sequence is equivalent to the 6 bytes:
uxn | #12 #34 OVR SUB DIV binary | a0 12 34 07 19 1b
Using stack-machine operations as primitives, along with a handful of arithmetic and bitwise functions, we find the resulting virtual machine with a comfortable 32 opcodes, leaving 3 bits in a byte for little extras.
A personal computer
What are computers for, anyway?
I think of a computer as a lens through which I can observe and listen to the natural world. Some mathematicians are of the opinion that the doing of mathematics is closer to discovery than invention. Mathematical beauty is the aesthetic pleasure derived from the abstractness, or orderliness of mathematics. Similarly to how one might enjoy spending time studying venation patterns, we can imagine a device to explore procedural music and parametric illustration.
This romantic vision of the luddite, potentially emancipating, power of computing was promptly smothered by military drones, surveillance hardware and the advertisement machinery. Suffice to say, that nowadays, to most of my friends, computing evokes either encroaching social networks or the drudgery of data entry.
Perhaps I'm making it more difficult than necessary by using the term personal computer, and not finding a more apt word to describe what I have in mind. This devlog is a summary of notes on the creation of a personal computer built upon the virtual machine documented in the previous post.
I. Personal
Let's consider the whole enterprise of designing and documenting this fictional computer to be a sort of model that others could adapt to their own designs, a call to encourage individuals to conjure up their own vision of a computing machine, tailored to suit their own needs; And Uxn, a demonstration of the potential of personal computing systems, and not as a platform that should be adopted and adapted to fit broader computing needs.
The purpose of this document is not to gather would be users, but instead review potential portable computing skills that are not platform-specific, and to serve as a reminder that the key to permaculture's resilience is achieved through a diversification of methods.
I am certain that making something unique by way of customization is necessary for care, for when the unique breaks, we might mend. I often think back on how, in the movie Hackers(1995), each character had their own laptop launch sequence reflecting parts of their aesthetics. — A far cry from today's disposable laptops, each equally adorned of proprietary services stickers.
For mending to even be envisaged, one must be able to generally understand that which needs to be mended; a venture which, thanks to the ever complexifying stack upon which modern computing is built, will have you promptly laughed out of the room. But just for the sake of our talking about virtual machines, our required understanding of the system shall end at its bytecode.
A side-effect of working from within unique computing environments is that looking for generic solutions is often more impractical than solving the problem head on. By that, I mean by that the solution needs to be adapted to the specifics of the virtual system, and this in turn develops understanding and care.
II. Computer
Our definition of a computer is the sum of potential I/O communications with the underlying virtual machine. In this case, the VM can communicate with up to 16 devices at once, but has no knowledge of what a screen or a keyboard might be, these devices are what make up the computer.
Uxn is to Varvara, what the 6502 is to the Classic Nintendo.
When it came time to find out how I might want to interact with this computer, I started with a terminal, it seemed as good a place as any to start off from, by terminal I mean a console to send and receive bytes of data. The terminal communication allows me to leverage the power of the host OS to further develop the system.
As the system begins to take shape, I consider that possibly someday I may lose my sight, or the use of my hands, or I may become deaf. I wonder how I might replace one device for another in the future, and how I might adapt each device to my changing needs. I leave some blank spaces to be filled at a later time, should I need them.
A programming language
It is fair to assume that programming with so few primitives, will make it difficult for compilers, and related tooling, to infer meaning from a program's source files. But we can still convey a lot of details about the intent of various data structures by encoding information in the few tools at our disposal.
I. Structural Editing
Let's consider the following uxn program, and associated symbols file, created with Drifblim:
hello.rom a001 1560 0001 0040 0005 9480 1817 2194 20ff f722 6c48 656c 6c6f 2057 6f72 6c64 21 hello.rom.sym 0018 write 0100 ( -> ) 0100 on-reset 0107 ( str* -: ) 0107 <print> 010a ( -- ) 010a <print>/while 010a ( send ) 010f <print>/ 010e ( loop ) 0115 hello-txt
It is possible to recreate a textual source file by walking through the program data, drawing from the symbols file, as: first the labels, second the sublabels, lastly the comments, and create the following valid program:
|0018 @write |0100 @on-reset ( -> ) ;hello-txt <print> BRK @<print> ( str* -: ) !& &while ( -- ) ( send ) LDAk .write DEO ( loop ) INC2 & LDAk ?&while POP2 JMP2r @hello-txt 48 65 6c 6c 6f 20 57 6f 72 6c 64
While this text stream can be reassembled into the program from which it originates, it will first need to be reformatted to be readable as a programming artifact.
|0018 @write |0100 @on-reset ( -> ) ;hello-txt <print> BRK @<print> ( str* -: ) !& &while ( -- ) ( send ) LDAk .write DEO ( loop ) INC2 & LDAk ?&while POP2 JMP2r @hello-txt 48 65 6c 6c 6f 20 57 6f 72 6c 64
By breaking on absolute padding, label tokens, non-defining comments, and tabbing the content of sublabels, we can improve readability further and can already return to something like what the original source file might have looked like:
|0018 @write |0100 @on-reset ( -> ) ;hello-txt <print> BRK @<print> ( str* -: ) !& &while ( -- ) ( send ) LDAk .write DEO ( loop ) INC2 & LDAk ?&while POP2 JMP2r @hello-txt "Hello 20 "World! 00
Finally, we can ensure that lines terminate on emiting opcodes(STZ/STR/STA/DEO) and some immediate opcodes(JCI, JMI). To make explicit that some routines are emiting, and therefore line-terminating, I chose to use the <label> format.
Labels marking the start of binary information use prefixes that communicate to the reassembler, how to handle the content. For example, txt for ascii characters, icn for 1-bit graphics and chr for 2-bit graphics.
II. Source Validation
Lacking data types, there is not much to go on as far as static validation, but there is still space to explore here. Type inference in Uxntal is done by checking the stack effect declarations of words, against the sum of stack changes predicted to occur based on the arity of each token in their bodies.
@add ( a* b* -: c* ) Warning: Imbalance in @add of +2 DUP2 ADD2 JMP2r
Words that do not pass the stack-checker are generating a warning, and so essentially this defines a very basic and permissive type system that nevertheless catches some invalid programs and enables compiler optimizations.
@routine ( a b -: c ) Warning: Imbalance in @routine of +1 EQUk ?&sub-routine POP2 #0a JMP2r &sub-routine ( a b -: c* ) POP2 #000b JMP2r
III. Graph Reduction
Routines are sequences of combinators that ingest values from the stacks, some permutations of these combinators are obviously redundant and reducing these extraneous transformations can be done on source files, for example:
#12 #34 SWP POP -> #1234 NIP
Tail-call optimization can be understood as a form of graph reduction, where jumps to subroutines followed by subroutine returns can be replaced instead by a single jump.
@routine ( a b -: c ) SWP ;function JSR2 JMP2r -> SWP ;function JMP2
Going one step further, routines that would otherwise terminate in a tail-call optimisation could even be relocated before their tail's location in memory and do away with the ending jump altogether. Incidentally, we see here a comment marker to indicate to the stack-effect checker that the routine's tail will fall-through.
@routine ( a b -: c ) SWP ;function JMP2 -> SWP ( >> ) @function ( a b -: c ) ADD JMP2r
I feel like I've only just begun to scratch the surface of what can be done with the language, and will update this document as new things are uncovered.
The previous notes contain experiments done with self-hosted tools, from the assembly, formatting, to the validation — each tool is written it the language that it assembles, formats or validates. Each program follows the same pattern of ingesting a file path, emitting errors and warnings through the Console/error port, and emits the same file path through Console/write on success, making them composable.