Even more Dauucumentation!

Here is the future documentation repository for Dauug|18, a subarchitecture of the Dauug|36 minicomputer for critical infrastructure and privacy seekers. Dauug|18 is not yet ready for physical implementation.

Please visit and support our sponsoring organization. Dauug|36 documentation lives here.

A tiny solder-defined CPU for immutable systems

Dauug|18 is an 18-bit architecture for owner-built CPUs, controllers, and minicomputers. Only maker-scale assembly tools are necessary, so this architecture can be implemented anywhere on the planet without a semiconductor foundry. All you need is a bare circuit board, a few dozen components, and some soldering practice.

Although Dauug|18 is highly flexible and programmable as a CPU, it is not a “use it for everything” gizmo. More specifically, Dauug|18 does not have preemptive multitasking, virtual memory, or any kind of data memory protection against local users (e.g. malware). So if you remember using MS-DOS around version 3.3, Dauug|18 has several of the same drawbacks. On the other hand, keeping remote attackers out (e.g. hackers) is quite straightforward due to the electrical constraints designed into the architecture.

Dauug|18 has an 18-bit address space. You get 262,144 words of data memory and not a word more. They’re 18 bits wide. And you get 262,143 doublewords of usable code memory. Each doubleword holds a single instruction that consists of 18 bits of control signals and 18 bits of literal data. Instructions don’t really have opcodes per se, just control signals. You can’t increase the RAM without adding some kind of kludgy segmentation or peripheral-based RAM.

Dauug|18 is not designed to swap code in and out of memory after startup. It may turn out in the final design that it won’t be electrically possible for Dauug|18 programs to alter code memory. This does not absolutely preclude loading and unloading applications on the fly, but such would have to reside in data memory and be interpreted. So BASIC, Scheme, Lua, and whatnot would have no problem if someone writes or ports an interpreter, but if you compile a C program into Dauug|18 machine code, it would need a hard reboot in order to execute.

Dauug|18 does not have any particular support for input and output (I/O), nor extra bus space sitting around. There are no interrupts or traps. Any peripherals you might find a way to attach will have to be polled and bit-banged by the CPU.

What is the purpose of Dauug|18?

Dauug|36 will use Dauug|18 internally as its coprocessor for firmware loading. One the Dauug|36 has booted and there is no further need to move firmware, the Dauug|18 will serve as a coprocessor for Dauug|36 input and output. Dauug|36 I/O is achieved by polling and bit banging; however, these tasks are handed off from the main CPU so it can run other code while Dauug|18 assembles, buffers, and exchanges packets with devices.

Outside of Dauug|36, Dauug|18 can provide system owners a “supply-chain firewall” in the sense that it contains no purchased or vendor-bundled complex logic, all the way down to the individual gate level. There’s no microprocessor at all, nor anything that could substitute for one such as an FPGA, PLD, or ASIC. So Dauug|18 is useful for modest-scale processes that require automation, but don’t require a hugely capable processor in terms of speed, word size, primary storage, or software updates.

Dauug|18 can also be an early project for people who wish to build or experiment with solder-defined computers, but don’t wish to assume the cost, labor, or diagnostic obligations involved with building a Dauug|36 computer as their first effort. The Dauug|36 CPU is approximately six times larger in size, components, and cost than Dauug|18’s.

What are more differences between Dauug|18 and Dauug|36?

To begin with, Dauug|36 has 36-bit words, preemptive multitasking, paged virtual memory, and memory protection. Dauug|18 has 18-bit words and none of those other capabilities. Further differences exist between the two architectures on account of fundamental differences in their electrical topology. One consequence is that the Dauug|18 and Dauug|36 assembly languages and assemblers are strongly divergent.

Relative to Dauug|36, Dauug|18 can do some tasks considerably faster. For example, to count the number of 1 bits in a word (this function is called population count or Hamming weight), Dauug|36 needs 8 clock cycles, but Dauug|18 takes only 3 clock cycles. It’s not an apples-to-apples comparison because the instructions include register fetching and updating on Dauug|36, but not on Dauug|18. The comparison becomes yet trickier because Dauug|18 may not need to touch a register before or after the computation, unlike Dauug|36.

Dauug|18 will be able to match Dauug|36’s clock speed, projected to be 40 MHz, but Dauug|18 can probably be clocked faster due to shorter circuit board traces. Dauug|18 is only one-sixth as large as Dauug|36. All Dauug|18 instructions execute in one clock cycle, although less work can be done per instruction that on Dauug|36, where each instruction takes four clock cycles. For instance, Dauug|36 can either add two words or shift one word by any number of bits in one instruction, but these tasks require two instructions on Dauug|18.

Could Dauug|18 run Doom?

Dauug|18’s 256Ki × 18 data memory won’t hold all of Doom’s music, textures, and graphics simultaneously without tradeoffs.

Is more technical information available?

Notes about Dauug|18 internals are available here.

Documentation license

This work is licensed under a Creative Commons Attribution 4.0 International License. For more information, see https://creativecommons.org/licenses/by/4.0/