calculusvaporis

ter/j1a/ver.... You can build it with Claire Wolf's iCEStorm (yosys, etc.) and run it on any but Lattice's tiniest FPGAs; it takes up 1162 4-input LUTs. - Ultraembedded's uriscv is about 11 pages of Verilog and implements the full RV32IMZicsr instruction set, including interrupt handling (but not virtual memory or supervisor mode): https://github.com/rolandbernard/kleine-riscv/tree/master/sr... In all three cases, this doesn't include testbenches and other verification work, but as I understand it, that's usually only two or three times as much work as the logic design itself. Maybe we should have a NaCpuDeMo, National CPU Design Month, like NaNoWriMo. I haven't quite done it myself. Last time I played https://nandgame.com/ it took me a couple of hours to play through the hardware design levels. But that's not really "design" in the sense of defining the instruction set (which is, like Thacker's design, kind of Nova-like), thinking through state machine design, and trying different pipeline depths; you're mostly just doing the kind of logic minimization exercises you'd normally delegate to yosys. In https://github.com/kragen/calculusvaporis I designed a CPU instruction set, wrote a simulator for it, wrote and tested some simple programs, designed a CPU at the RTL level, and sketched out gate-level logic designs to get an estimate of how big it would be. But I haven't simulated the RTL to verify it, written it down in an HDL, or breadboarded the circuit, so I'm reluctant to say that this qualifies as "designing a single CPU" either. (Since it's not 01982 anymore maybe you should also include a simple compiler backend before you say a new ISA is really designed?) But I also wouldn't say I'm "well versed in the topic". I can say things about what makes CPUs fast or slow, but I don't know them from my own experience; I'm mostly just repeating things I've heard from people I judge as credible on CPU design. But what is that credibility judgment based on? How would I know if I was just believing a smooth charlatan who doesn't really know any more than I do? And I think Rob is in the same situation as I am, just worse, because he has even less experience.

/calculusvaporis, is one possibility. Another would be a simple register machine, something like the PIC; also in 2014, I wrote a proposal for a nearly-MOV-machine version called "dontmove" at http://canonical.org/~kragen/sw/aspmisc/dontmove.md. The C implementation at http://canonical.org/~kragen/sw/aspmisc/dontmove.c compiles to 855 bytes of i386 machine code (38 .init, 784 .text, 23 .fini, 10 .rodata) and is dramatically more efficient than a simple BF implementation, and unlike BF, it has features like memory indexing and subroutine calls; but it's not as well tested. Each of BF and Dontmove took me about half an hour to implement. Even though a simple Dontmove implementation is exponentially faster than a simple BF implementation, it's still orders of magnitude slower than native code. I'm still exploring how to better bridge that gap; ideally implementing the virtual machine wouldn't take the entire afternoon that is the goal of Chifir, and it wouldn't run as slow as Chifir. I suspect that some kind of SIMT architecture (like GLSL and GPUs in general) might be the right path, allowing a simple emulator to amortize interpretation overhead over many lanes of data. I expect Alan would be allergic to this idea. As mentioned in the Cuneiform paper, Lorie and van der Hoeven have published some papers on what they call a Universal Virtual Computer, directed at archival, but unfortunately some of the design decisions in the UVC run strongly counter to the goal of ensuring that from-scratch implementations have a good chance of being compatible: bignum registers, for example, and complicated fundamental operations like float division. The consequence is that writing emulators to run on the UVC should be very easy, but no two implementations of the UVC will be compatible, so those emulators will not run successfully on new implementations of the UVC written after we are all dead. An issue barely mentioned in this paper is I/O devices. You'll note, for example, that Chifir has no mouse and no real-time clock, although it does have a keyboard and a framebuffer; its keyboard interface is somewhat underspecified but appears to lack control, alt, or other similar modifier keys, and there are no key-release events, and as abecedarius points out, reading the keyboard is blocking. This means that it will be impossible to write simple video games for Chifir that move your guy only as long as you hold down a key, and the lack of a real-time clock means that it can't do animations at a constant speed. It's likely that the specification and implementation of I/O devices for an archival virtual machine will require as much effort as that of the CPU.

ssible ELF executable, which turns out to be 45 bytes, which unfortunately has been broken by recent Linuxes: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm... Based on Brian's work, I wrote a self-compiling compiler for a tiny dialect of Forth: https://github.com/kragen/stoneknifeforth which is about two pages of code if you remove the comments. I also wrote a PEG compiler-compiler in JavaScript which is one page of code: https://github.com/kragen/peg-bootstrap/blob/master/peg.md --- ultimately I want to make a version that generates StoneKnifeForth code instead of JS, but I haven't gotten around to it. I also designed a minimal CPU architecture: https://github.com/kragen/calculusvaporis but I only have software implementations for it so far, and no interesting code. And I wrote a metacircular interpreter for Bicicleta in half a page of code, which I guess is some kind of "minimal coding example": http://lists.canonical.org/pipermail/kragen-hacks/2007-Febru... https://github.com/kragen/screenfuls is a collection of tiny, readable programs that do interesting things.

on), or a little higher than that of a Curta calculator (600 parts for Type I). The Clock of the Long Now uses steel gears on stone and ceramic bearings. It contains some mechanical binary calculation (and the prototypes are the most beautiful machines I've ever seen) but it's not a programmable computer.