The result isn't an identical binary to before, and it segfaults when run. But it's bugfix seven. A couple of places where we make .subx files a little more strict: a) All .subx files must define a data segment. Even if they have no data. b) All .subx files must define an `Entry` label for the binary to start at. Earlier we used to default to the start of the code label. That's not too hard to add; we'd just need to: i) rename `get` to `get-or-abort` ii) clone a third variant of `get-or-insert` called `get` that returns null if the key is not found. iii) use `get` rather than `get-or-abort` when looking up the `Entry` label. |
||
---|---|---|
.. | ||
ex1 | ||
ex1.subx | ||
ex2 | ||
ex2.subx | ||
ex3 | ||
ex3.subx | ||
ex4 | ||
ex4.subx | ||
ex5 | ||
ex5.subx | ||
ex6 | ||
ex6.subx | ||
ex7 | ||
ex7.subx | ||
ex8 | ||
ex8.subx | ||
ex9 | ||
ex9.subx | ||
ex10 | ||
ex10.subx | ||
ex11 | ||
ex11.subx | ||
ex12 | ||
ex12.subx | ||
Readme.md |
Small example programs, each with a simple pedagogical goal.
They also help to validate SubX instruction semantics against native x86 hardware. For example, loading a single byte to a register would for some time clear the rest of the register. This behavior was internally consistent with unit tests. It took running an example binary natively to catch the discrepancy.