Writing a P2 Simulator in Elixir
When you look at the minicomputers of old they were glorious. They had all the things that you could ever want from a computer. Gleaming metal, flashing lights, switches that allow you to modify individual bits in memory or storage on demand. On many of them, you could step each instruction watching the values of registers change as each instruction execute. It was bare metal, you could touch your computer’s soul.
In the modern age, the only way you can get that close the metal is to go to microcontrollers. Regular CPUs are now way too abstracted… they’re practical, pragmatic, but superficial.
The quintessential minicomputer console - the PDP/11
Enter, the P2.
There’s a new kid on the block. Okay, the ‘kid’ has been in development for 13 years but it’s a CPU that has been optimized in such a way that writing in assembly is a dream. Don’t get me wrong, you cam still write code in C if you want… but I really love assembly. I love the honesty of it.
Here’s the kicker - at the time of writing, only 10 of these exist in the world.
(a hundred more should hit developers in the next 2-3 weeks to shake out the final bugs before first production runs…)
P2 Specifications
This is a multi-core uC from the very beginning. The processor at a high level contains eight (8) identical cores that all have identical access to on-die shared memory (called HUB memory), and 64 individually programmable I/O pins.
Here’s an abridged version of the spec:
Every one of the eight cores has:
- Access to all I/O pins.
- 4k of RAM (2k is private, 2k can be inspected/modified by another core) - “Stupid Fast Memory”.
- Code can be executed from above core memory, or from the shared memory area (“Much more, but not-so-fast” Hub Memory).
- Certain types of data copying/processing can be offloaded to “streamers” which run independently of the cores and write data to the above private memory (think DMA).
- Specific Assembly Instructions designed to make writing your OWN language interpreters trivial.
- VGA / Composite / Soon-to-be HDMI output - native.
- Hidden debug interrupt support for single-stepping, breakpoints, and polling. Hidden debug interrupt for single-stepping, breakpoint, and polling
The Hub has:
- 512k RAM
- Clockable up to 280Mhz
- Every pin has modes. These modes include “GPIO”, “Async / Sync Serial”, “DAC”, “ADC”, “USB”, “Quadrature” (I mention them because they’re the ones I understand… there are many I don’t"
Full docs live here:
https://docs.google.com/document/d/1UnelI6fpVPHFISQ9vpLzOVa8oUghxpI6UpkXVsYgBEQ/edit
So you’re building a minicomputer?
In the long term? Yes.
(do you think it will be a badge?)
Maybe ;-)
But why a minicomputer? Why not just port the erlang virtual machine to it?
Let’s compare the P2 to other minicomputer CPUs of old
Atrribute | PDP-11 | Z80 | Propeller P2 |
---|---|---|---|
Clock Speed | 15.2Mhz | 2.5Mhz | 280Mhz |
Number of Registers | 8 x 16 bits | 20 x 8 bit, 4 x 16 bit | 1024 x 32 bits |
Instruction Format | 16 bits | 8 bit, 16 bit, 24bit, yolo - lol | 32 bits |
Memory | 256k | Typically 64k | 512k (on die) |
Number of Cores | 1 | 1 | 8 |
…
So clearly, the P2 is easily capable of not only being a full minicomputer in its own right, the the additional cores can be set up to drive network / video / keyboard / paper-tape readers and other assorted IO devices.
Why are you talking about hardware when this article talks about building an emulator?
(Maybe I am thinking of doing a hardware port of the erlang virtual machine)
So we have:
- a uC with 8 cores.
- An Assembly language that is specifically written to make writing bytecode interpreters trivial.
- If I were to port erlang to this uC, I would want to look at being able to scale the number of processors indefinately.
- How do I model that?
- How about if our Propeller Core is emulated in elixir as an erlang process… then I could test scaling into the hundreds of thousands of uC cores (cogs).
What’s next?
- Write a disassembler.
- Write a P2 emulator.
- Build the hardware version to compare against emulator.
- Use XBYTE and friends to write a native erlang bytecode interpreter.
- Scale
- Profit! (Well, probably not).
Truth is, I’m going to learn a TON. I’m going to learn a ton about how computers really work, how the erlang virtual machine REALLY works, and… most importantly I will be back at the individual bits where I belong.
Wanna Play?
One proposed layout for the P2 minicomputer console…
psst… so I guess I didn’t get to the Elixir part by the end of this article. You should go to the next article as that’s when we start writing code