path: root/subx/Readme.md


              
## The SubX VM

Bytecode interpreter for a subset of the 32-bit x86 ISA.

* Only instructions that operate on the 32-bit E*X registers. (No
  floating-point yet.)
* Only instructions that assume a flat address space; no instructions that use
  segment registers.
* No instructions that check the carry or parity flags; arithmetic operations
  always operate on signed integers (while bitwise operations always operate
  on unsigned integers)
* Only relative jump instructions (with 8-bit or 16-bit offsets).

These rules yield a clean instruction set. We don't care about running
arbitrary binaries, just those generated by our forthcoming Mu compiler.

Targeting a VM enables more comprehensive tests for the compiler, without
requiring access to processor/memory state without getting bogged down in
details of the ELF format, ABI, STABS debugging format, etc., etc.

Having the VM implement a real (and ubiquitous) instruction set makes it easy
to generate native binaries outside of tests.

Just unit tests so far:

  ```
  ./subx test
  ```

x86 instruction set resources used in building this:

* [Intel programming manual](http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf) (pdf)
* [Concise instruction reference](https://c9x.me/x86)
* [Single-page cheatsheet](https://net.cs.uni-bonn.de/fileadmin/user_upload/plohmann/x86_opcode_structure_and_instruction_overview.pdf) (pdf)
## The SubX VM

Bytecode interpreter for a subset of the 32-bit x86 ISA.

* Only instructions that operate on the 32-bit E*X registers. (No
  floating-point yet.)
* Only instructions that assume a flat address space; no instructions that use
  segment registers.
* No instructions that check the carry or parity flags; arithmetic operations
  always operate on signed integers (while bitwise operations always operate
  on unsigned integers)
* Only relative jump instructions (with 8-bit or 16-bit offsets).

These rules yield a clean instruction set. We don't care about running
arbitrary binaries, just those generated by our forthcoming Mu compiler.

Targeting a VM enables more comprehensive tests for the compiler, without
requiring access to processor/memory state without getting bogged down in
details of the ELF format, ABI, STABS debugging format, etc., etc.

Having the VM implement a real (and ubiquitous) instruction set makes it easy
to generate native binaries outside of tests.

Just unit tests so far:

  ```
  ./subx test
  ```

x86 instruction set resources used in building this:

* [Intel programming manual](http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf) (pdf)
* [Concise instruction reference](https://c9x.me/x86)
* [Single-page cheatsheet](https://net.cs.uni-bonn.de/fileadmin/user_upload/plohmann/x86_opcode_structure_and_instruction_overview.pdf) (pdf)