Designing an ISA

19 Oct 23

I stumbled across Devine Lu Ator's uxn project. uxn is an instruction-set architecture (ISA) - the lowest form of a computer that can be programmed. Devine's philosophy behind the project is that the ISA should be simple enough that an emulator can be written in a weekend. This means the specification can be included with and software written for it, and that software is safe from its target architecture being lost. Designing an ISA purely for a software implementation is an interesting take. This removes some limitations that hardware comes with and lets you make some interesting choices. I decided to design an ISA without concern for a hardware implementation for fun.

I've taken a few university classes on assembly and ISAs, so I'ms ure several of my design decisions come from what we did in those. I started out with a memory size of 0xFFFF, an arithmetic logic unit (ALU) with 2 input registers and 1 output register, a return stack of 256 entries, a user-data stack with 256 entries, and 8 IO ports that are 2 bytes wide. I also decided to have 8 interrupt vectors: some for timers, keyboards, etc. As I wrote out the instructions and some sample assembly programs, I modified these specs.

I started the detailed design with the instructions since these are the part of the architecture that people interact with the most.

Initially, I wanted each memory address to contain 4 bytes, a full instruction. The problem was that when using memory to store variables, I had to specify if I wanted the lower 2 bytes or the upper 2 bytes. If the variable was a pointer, I had to specify lower/upper again. Potential solutions include:

changing the memory layout
make variables only refer to the lower bytes
don't allow pointers directly from memory - load them into register then point

I made the decision to have each memory entry/address be 2 bytes wide. But with each instruction and operands being 4 bytes wide, each instruction will take up 2 memory addresses. To make this happen, the PC is incremented by 2 each time. This makes programming a little harder since we're counting by 2's, but it allows for much more elegant use of pointer variables.

You can still use odd-numbered memory for storage, but instructions will take up 2 slots. This solution allows for full self-modification. The program can write to any space in memory and replace parts of itself. I don't know what this would be useful for, but it's a thing.

In my classes and in Ben Eater's "building a breadboard computer" series, the architecture used a couple registers that get loaded with values, operations are done, and the results are stored in memory. For this machine, I decided to make a couple memory spaces take the role of registers. The register that holds the results is also a memory space. This all means the results memory slot can be directly loaded with a value to immediately check for JMPEQ, JMPPOS, etc.

0xFDFC is input1, 0xFDFD is input 2, and 0xFDFE is the 4-byte output. Having a large output will help prevent overflows

In addition to the register-oriented operations I'm used to, I decided to devote some instructions to stack operations, including all the math and bitwise operators that the "registers" get. This gives flexibility to the programmer at the cost of some implementation complexity. I may also add some instructions for uniquely stack-focused operations, like swapping the top to stack items, swapping the 1st and 3rd items, etc.

There are some traditional registers for system values like the Program Counter, stack pointers, etc:

2 bits of the opcode are reserved for specifying the addressing mode. I defined 3: literal, direct, and indirect. literal is where the operand is included in the instruction, direct is where a memory location is specified, and indirect is where a memory location is specified and that location contains another memory address. Indirect addressing is like using pointers in C. These would be useful for looping over memory, e.g. when a section of memory contains a string of characters, and the contents of our pointer/index is incremented each loop.

Along with the instructions, there need to be a few additional features to make the language complete. The language needs to support assembler directives that the CPU won't execute, but will do things like pre-populate memory with certain values, replace variable names with their actual memory address, etc. These are outlined here:

Hello World:

#string F000             // declare variable
$string "Hello World!"   // populate memory with string
#index FD00              // declare variable

push string              // push address onto stack
pop index                // pop address into pointer variable
@loop                    // start of loop
	write >index 0x00    // write contents of [index] to cout
	inc index            // increment index
	load >index 0xFE     // load contents of [index] to accumulator
	jmpne /loop          // if accumulator != 0, jump to loop start