| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
I don't know how to tell nasm to generate an imm32. It's a minor stepping-stone
anyway; just emit the machine code directly.
|
|
|
|
| |
Turns out it was an open question I never got around to answering.
|
|
|
|
| |
Here's a few test binaries generated on 32-bit Linux.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New plan: spend some time learning to program in machine code atop subx,
relying solely on a tiny subset of kernel-provided syscalls. Gradually
introduce helpers.
Helpers we're sure we don't need, so far:
a) Nested expressions
b) Garbage collection
c) One-size-fits-all memory allocation primitive
d) Function overloading and generics
Helpers we're sure we need, so far:
a) Dependency-injected versions of syscalls
b) Tangling directives
c) Statically checked types
Workflow for a C translator from ascii to binary:
a) run generated machine code atop subx (unit tests probably go here)
b) emit machine code packaged as an ELF file
c) check that the ELF binary runs natively
d) check that the ELF binary can be unwrapped and run atop subx
This is different from a conventional compiler because the 'HLL' is
unconstrained.
It is also different from Forth given the emphasis on types.
We want a simple stack that also encourages code sharing between
programmers. Conventional languages grow monotonically complex. Forth
discourages code sharing; it is non-trivial to figure out the 'shape' of
data a strange function expects on the stack.
|
|
|
|
|
|
|
|
| |
Just ran into first issue from using the portable /bin/sh rather than a
modern shell:
https://stackoverflow.com/questions/15744421/read-command-doesnt-wait-for-input
Turn on errexit everywhere.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Fix CI by dropping some accidental copy-pastes.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Incomplete implementation of `xchg` since commit 4175.
|
|
|
|
| |
Fix CI.
|
| |
|
|
|
|
| |
Temporary hack to debug Kragen Sitaker's VM.
|
| |
|
| |
|
|
|
|
| |
subx: 'call' and 'return' instructions
|
|
|
|
|
| |
subx: extract helpers for 'push' and 'pop'. We will be using them in
'call' and 'ret' as well.
|
|
|
|
| |
subx: 'pop'
|
|
|
|
|
| |
subx: correct a 'copy' ('mov') instruction as well to get its operand
right from the opcode.
|
| |
|
|
|
|
|
|
|
|
| |
subx: correct 'push' register. It gets its operand right from the
opcode, not a new modrm byte.
Have I misinterpreted any other instructions in this manner (`+rd` in
the Intel manual)?
|
|
|
|
| |
subx: 'pop'
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
subx: conditional jump instructions
Lots of boilerplate here. This commit really strains my 'copyista'
ethic. But I think it's still clearer to see each instruction
implemented independently than to try to create a macro or something
like that.
|
| |
|
|
|
|
| |
subx: unconditional 'jump'
|
| |
|
|
|
|
| |
subx: 'mov'
|
|
|
|
|
|
| |
I spent a while spelunking into the code generated by C compilers before
realizing that ignoring the order of arguments for 'cmp' instructions
clarifies everything.
|
|
|
|
|
|
| |
subx: 'compare'
Hopefully I've implemented the 'sense' of comparisons right..
|
| |
|