The world definitely needs another VAX emulator!

The world definitely needs another VAX emulator!

I am making a VAX emulator.  I call mine ReVAX and I have put the current code up on github:

(It doesn't really work yet -- there's about 10,000  lines of code + almost as much code for tests and experiments.  It should be able to run code Really Soon Now, though.  Just another 1000 lines, I swear!)

There are already three existing open-source VAX emulators (eVAX, TS10, SimH) and at least one commercial (CHARON-VAX).  So why does the world need another one?

Partly because I need one.  This one is mine.  Partly because the code in the others is hard to follow (SimH more so than eVAX and TS10).  Partly because none of them implement the VAX in a hardware realistic manner.

David Patterson and John Hennessy won the Turing Award a few days ago, largely for claiming that the VAX was a very bad computer architecture and that they had this nifty idea called RISC that was so much better.

I thought they were right -- until I actually read up on the VAX back in 2005.  It seemed remarkably clean and small to me, as I was used to the x86.  And I knew the x86 could run really fast and efficient, so why should it be impossible to make the VAX run really fast and efficient?

This emulator is my attempt to look into that question.

In contrast to the other three open source emulators, ReVAX uses "microcode"  in the sense of 3-address load/store RISC-like vertical microcode that implements almost all of the architecture, including handling all the (far too) many addressing modes the VAX has.

That microcode runs on a really simply 32-bit pipelined microarchitecture (DECODE/EXE/WB/MEM) with a register block, a simple ALU, a 64-bit shifter, and a multiply/division unit.

There is a "microcode assembler" that turns the microcode source into a C file with a bunch of magic #define's, some enum's, some struct types, and a big array that contains the compiled form of the microcode.

All the addressing modes -- and there are many and they are tricky! -- are specified in a text file that gets converted to code by a 1K line Perl script.  This spec/script combination generates code to assemble operands, to disassemble operands, to decode operands (for the simulator), and to validate operands (which checks that certain invalid register combinations aren't used, for example).

The other three all uses hand-written C code to decode operands and to implement each instruction.  Lots and lots of hand-written C code.

Current status:
  • the assembler doesn't work
  • the disassembler doesn't work
  • the simulator doesn't work
  • VAX floating-point numbers can be converted correctly to/from strings
  • big integers are supported (the VAX has 1/2/4/8/16-byte integers)
  • the generated operand parsing/assembling code pretty much works
  • the generated operand disassembly code pretty much works
  • almost all the low-level code has been fuzz-tested with American Fuzzy Lop
  • a lot of the low-level code (and operand handling code) has been unit tested
  • there is a nice parsing module for the assembler (and for the .ctrl file the disassembler is going to get)
  • the ALU microinstructions are not written yet but I have a good sketch of how to write them
  • the set of microinstructions is finalized
  • most of the simulator's decoder is written, including some hand-written AND autogenerated tables that together help in piecing together the correct microcode for all addressing modes (this is trickier than it sounds)
  • most of the microcode to handle addressing modes is written
  • some of the reset/initialization microcode is written
  • some of the ALU instruction microcode is written
  • the readme's are almost as good as I want them to be
  • doc/implementation.txt starts out good but it contains lots of old and messy text, some of it even in Danish.  It needs cleaning up.
  • doc/vaxarchitecture.txt is quite nice
  • doc/unhappy-code.txt describes code and decisions I'm not quite happy with -- this was a great document to have!
  • doc/retrospective.txt looks back on the major decisions I took with the project -- this was a great document to have!
  • doc/por1.txt, por2.txt, por3.txt -- "Plan of Record", what is the current strategy I take to move forward with the project?

Other posts about ReVAX:

(none so far)