| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
As we add high-level constructs we'll start labeling low-level
constructs as unsafe, and highlighting them in red in our editor.
|
| |
|
|
|
|
|
| |
No need for it once the program's loaded. And we keep programs from
running the header as code.
This also simplifies the header computation in the translator.
|
| |
|
|
| |
Clarify a few happy accidents.
|
| |
|
|
|
| |
The source 'language' is still entirely open. We'll see how it evolves
as I write programs in machine code.
|
| |
|
|
| |
Give subx too the recent support for running a single test.
|
| |
|
|
| |
Fix CI. Looks like 'std::' sometimes doesn't work.
|
| |
|
|
| |
Make prints uniform.
|
| | |
|
| |
|
|
| |
Hopefully I won't need much more than exit, read and write.
|
| | |
|
| |
|
|
|
| |
We're now parsing the ELF spec more closely and better handling multiple
program header table entries.
|
| | |
|
| |
|
|
|
| |
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'
|
| | |
|
| | |
|