• Instruction Set and Addressing Modes

    Anthony Faulise • 03/21/2025 at 13:01 • 0 comments

    I think my first tasks are to define my instruction set and addressing modes, i.e.; the "Instruction Architecture".


    I’m going to steer clear of a full CISC instruction set. Forget polynomial evaluation, floating point, and single-instruction block transfers or string lookups. 


    After reviewing manuals for the Motorola 6800, Motorola 68020, Zilog Z-80, Digital PDP-11, and MIPS RISC designs, I ‘ve settled on these instructions as sufficient to do anything I would need:

    • LD (load)
    • ADD, ADC - add with and without carry
    • SUB, SBC - subtract with and without carry
    • CMP (compare)
    • AND
    • OR
    • NOT
    • XOR
    • NEG (negate)
    • INC
    • DEC
    • Rotate (right/left with/without carry)
      • RR, RRC
      • RL, RLC
    • Shift (right/left arithmetic/logical)
      • SRA (arithmetic new MSB = old MSB), SRL (logical new MSB = 0)
      • SL
      • SLB, SRB (shift left/right 1 byte)
    • BRA (relative jump on a variety of conditions, 1 word instruction)
    • JMP (absolute jump on variety of conditions)
    • JSR (jump to subroutine)
    • IM (set interrupt mask)
    • SETC (set CCR carry bit)
    • CLRC (clear CCR carry bit)
    • RTS (return from subroutine)
    • SWI (software interrupt)
    • RTI (return from interrupt)
    • NOP (no operation)


    I also feel my CPU needs to support these addressing modes:

    • Implicit (no operand)
    • Immediate (operand follows instruction in program memory)
    • Register
    • Indexed (address of operand is immediate address plus offset contained in a register)
    • Indirect (content of register is address of operand)
    • Indirect with pre-decrement of register (nice to have, but negotiable)
    • Indirect with post-increment of register (nice to have, but negotiable)
    • Doubly Indirect (content of register is the address of the address of the operand)


    From my research, there are some addressing modes the M68020 has (and I think the VAX too) that I thought I might like, such as "Address Register Indirect with Index" where the address of an operand is a register, plus a constant times a second register, plus a fixed displacement. This is really convenient for accessing arrays of objects, where the base register is the start of the array, the “constant” is the size of the object, the register that multiplies the constant is the index in the array, and the final displacement is the offset within the object of the member value you want to access.  I’ll have to live without it.


    I was unsure initially about how many registers I wanted to support. My experience with the M6800 left me feeling that two registers was not enough. The Z-80’s accumulator plus six 8-bit or three 16-bit registers seemed to be the bare minimum. I left the question open, but came to a conclusion from another angle.


    I didn’t want to deal with a combination of single-word and multi-word instructions, so I preferred that the instruction word should be able to contain the entire instruction, addressing mode, and source and destination register information. For immediate mode addressing, I was going to have to live with fetching the operand in the word after the instruction. I may be able to squeeze the (8-bit) relative offset of a branch instruction into the 16-bit instruction word if I’m creative. I’ll leave that for later.


    My first thought was to have a certain bit-field in the instruction word for the instruction itself, then other bit fields for the addressing mode and register ID of each operand. If I allowed 3-bits for addressing mode and 3-bits for register ID for each of two operands, that would occupy 2 x (3 + 3) = 12 bits of my 16-bit word. That left just 4 bits to encode my 22-plus instructions.


    At first, I saw my 8 registers melting away to two, but then I had an insight (OK, "insight" might just have been remembering it from someone else's architecture). Only a few instructions require two operands: LD, ADD, ADC, SUB, SBC, CMP, AND, OR, XOR. That’s 9. I can allow 4 bits to encode those, and if all 4 bits are 1s, say, that could indicate that the instruction was a one-operand instruction, and that the next 6-bits of the instruction word, no longer needed to encode the...

    Read more »

  • Inception

    Anthony Faulise • 03/19/2025 at 19:26 • 0 comments

    When I was 14, I built an Altair 680b computer from a kit. This was in the earliest days of personal computing. Earlier than that, even. There were instructions. There was a technical manual. There was a CPU manual. But it came with no software, no operating system, no applications. There was not even a hard disk. For the first six months I had the machine, there was no way to save a program; everything was lost the instant I turned the computer off.


    Generic Altair 680b (https://www.retrotechnology.com/restore/altair680.html)

    Later, I bought a 16K memory card (for $600 IIRC). It came with a text editor, an assembler program, and a debugger program. But, they were on paper tape, and I did not have a paper tape reader. I spent a lot of time looking at the paper tapes I had, longing for a tape reader or an assembler program I could use.


    Eventually, I purchased a cassette tape interface, so I could store programs. As it happened, the tape interface came with a 4K Basic interpreter, on cassette tape. So, I finally had a programming language I could use, even if it did take 10 minutes to boot up. For a while, I forgot about an assembler. I wrote programs in Basic.


    Years later, I decided to build a Z-80 based S-100 computer. I bought a CPU card, a 64K RAM card, a disk controller and two eight-inch floppy disk drives. But I never got the pieces to work together, and never wrote any code on that machine. By that time I was in college, writing code in C on a VAX-11/750. I was in heaven. I put the Z-80 parts in a box in my parents basement and forgot about them.


    Recently, forty years later, I found the box of Z-80 parts in my own attic. I thought about putting them back together. And I realized: I had no operating system, no interpreter or compiler, no software. What would I do with my Z-80?


    So, as I began assembling the parts to reconstitute the computer, I decided to write my own Z-80 assembler. From scratch. From first principles. Not copying anyone else’s design or code. 


    I studied the Z-80 CPU databook. I thought about what I had learned while earning a bachelors and then a master’s degree in computer science. (If I have time, I'll try to weave my development notes into a separate blog.) After I finished the assembler, and tested it on a Z-80 emulator (I haven’t finished the Z-80 hardware yet), I happened to re-read a book, The Soul of a New Machine.


    The Soul of a New Machine, by Tracy Kidder, chronicles a small team of engineers at Data General, a mini-computer manufacturer in Massachusetts, working in the late ‘70s to design the next generation 32-bit mini-computer. I’d read the book in college, probably in 1983 or 1984. The first time, it was inspiring, but like a dream. The second time, I wondered “Could I have worked on that team? Could I have done what they did?”


    Only one way to find out...


    Here's what I'm hoping to achieve:

    • Design and build a micro-coded 16-bit CPU that could easily be extended to 32-bits just by widening the data paths
    • Include enough support for full-fledged operation of a UNIX-like operating system, meaning
      • Virtual memory
      • Supervisor / privileged / user modes
      • Multi-tasking
      • Efficient context / process switching
      • Priority interrupts
      • DMA
      • Hard disk
    • Include a few fun features. At the moment, that means:
      • Memory cache to keep routine data / instruction fetches off the system bus so the DMA system can do things like file transfer and page swapping efficiently
    • As much as possible, stick to early-'80s technology like 74LS series TTL
      • No FPGAs
      • I do get to use an IDE/ATA disk (ok, that's a cheat)