| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've extracted it into a separate binary, independent of my Mu prototype.
I also cleaned up my tracing layer to be a little nicer. Major improvements:
- Realized that incremental tracing really ought to be the default.
And to minimize printing traces to screen.
- Finally figured out how to combine layers and call stack frames in a
single dimension of depth. The answer: optimize for the experience of
`browse_trace`. Instructions occupy a range of depths based on their call
stack frame, and minor details of an instruction lie one level deeper
in each case.
Other than that, I spent some time adjusting levels everywhere to make
`browse_trace` useful.
|
| |
|
|
|
|
| |
Now that our test runs are getting longer, debugging is again becoming a
bottleneck. Time to start using trace depths along with `mu browse-trace`
from the top-level.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Standardize name for 'end of file' sentinel. `eof` seems like an ordinary
variable, and `EOF` looks too much like a register (particularly in code
like `if (EAX == EOF)`), so we'll go with `Eof`. Consistent capitalization
for globals, and constants are globals too.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Considering how much trouble a merge phase would be (commit 4978), it seems
simpler to just add the extra syntax for controlling the entry point of
the generated ELF binary.
But I wouldn't have noticed this if I hadn't taken the time to write out
the commit messages of 4976 and 4978.
Even if we happened to already have linked list primitives built, this
may still be a good idea considering that I'm saving quite a lot of code
in duplicated entrypoints.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Fix CI.
|
| |
|
|
|
| |
Support immediate operands in the data segment in all the ways we support
them in the code segment.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Standardize how we show register allocation decisions.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Build the C++ version optimized by default when building/running all apps.
We have enough apps now that the cost of optimized builds is worthwhile.
|
| | |
|
| |
|
|
|
| |
I think I don't need to special-case packing for different segments. That
should massively cut down on the number of tests.
|
| |
|
|
|
| |
It's always seemed ugly to explain the rules for segment names. Let's just
always require a fixed name for the code and data segments.
|
| |
|
|
| |
(excluding tests)
|
| | |
|
| | |
|
| |
|
|
| |
Starting to build up Phase 2 (apps/pack) out of recently designed primitives.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Cleaner way to compare streams in tests.
|
| | |
|
| | |
|
| |
|
|
|
| |
This seems like the final helper we need for Phase 2. Now to build the
business logic itself.
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
Improve syntax highlighting in the Readme.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|