8a0268317f
subx: extract helpers for 'push' and 'pop'. We will be using them in 'call' and 'ret' as well. |
||
|---|---|---|
| .. | ||
| 000organization.cc | ||
| 001help.cc | ||
| 002test.cc | ||
| 003trace.cc | ||
| 003trace.test.cc | ||
| 010core.cc | ||
| 011direct_addressing.cc | ||
| 012indirect_addressing.cc | ||
| 013immediate_addressing.cc | ||
| 014jump_relative.cc | ||
| 015jump_relative.cc | ||
| Readme.md | ||
| build | ||
| build_and_test_until | ||
| cheatsheet.pdf | ||
| clean | ||
| opcodes | ||
| subx | ||
| test_layers | ||
| vimrc.vim | ||
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: