Phase 1: coalesce different instances/fragments for each segment, correctly
prepending later fragments.
Phase 2: pack bitfields into bytes.
Phase 3: compute addresses for labels, compute the ELF header.
Phase 4: convert hex bytes to binary.
But ugh, phase 1 involves linked lists and I'll have to go down a rabbit
hole building up more standard library functions.
I've been allowing operands in any order just because it simplifies implementation.
I don't actually rely on this flexibility; all the .subx programs in this
repo consistently use a single ordering.
Why is a hard-coded canonical order hard to implement? The order that seems
most logical to me is complicated by the "reg" bits in the ModR/M byte:
- In instructions that interpret it as an `/r32` operand, it needs to be
deemphasized because it refers to a different argument of the instruction
than the `/mod`, `/rm32`, `/base`, `/index` and `/scale` operands that
capture the bulk of instruction decoding complexity and so should be
emphasized. `/r32` can also be unused, which strengthens the case for
deemphasizing it.
- In instructions that interpret the "reg" bits as a `/subop` operand,
it should be colocated with the opcode because it performs the same function:
specifying the *operation* the instruction performs.
In both cases, the bits in the `reg` bitfield are conceptually unrelated
to the other bitfields in the same byte. But they sometimes want to be
close to the opcode bytes on the left, and at other times need to be deemphasized
rightward. Fixing both these possibilities seems complicated and stateful,
particularly since all operands are optional in general. On the other hand,
just pulling operands you need to create each byte, regardless of where
in the instruction they occur, that's nicely stateless.
So far I've been assuming that I'd just statelessly convert each line in
a .subx file. But over the past week or so of constant interruptions I
gradually realized that code and data need different parsers.
Some of them are no longer useful; drop them.
For the rest, have useful usage messages. And also be a little more principled
in where we introduce CFLAGS, and where we expect it to come in from the
commandline.
I'm choosing not to call gen/run/dgen/drun from test_layers because it
makes test_layers harder for newcomers to read. The scripts aren't the
first thing people should see, they're just useful once you're up and running
hacking on SubX.
Bugfix: has-metadata? was corrupting registers
Seems uneconomic to write tests for stuff like this. Assembly is just not
the right layer to try to come up with a general solution or process. Keep
running your code and wait to find signs of breakage.
Kartik Agaram