| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Make the first instruction described something that doesn't touch flags,
so we don't introduce too much complexity all at once.
|
| |
|
|
| |
Inline some macro definitions.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've been saying for a while[1][2][3] that adding extra abstractions makes
things harder for newcomers, and adding new notations doubly so. And then
I notice this DSL in my own backyard. Makes me feel like a hypocrite.
[1] https://news.ycombinator.com/item?id=13565743#13570092
[2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning
[3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2
The implementation of the DSL was also highly hacky:
a) It was happening in the tangle/ tool, but was utterly unrelated to tangling
layers.
b) There were several persnickety constraints on the different kinds of
lines and the specific order they were expected in. I kept finding bugs
where the translator would silently do the wrong thing. Or the error messages
sucked, and readers may be stuck looking at the generated code to figure
out what happened. Fixing error messages would require a lot more code,
which is one of my arguments against DSLs in the first place: they may
be easy to implement, but they're hard to design to go with the grain of
the underlying platform. They require lots of iteration. Is that effort
worth prioritizing in this project?
On the other hand, the DSL did make at least some readers' life easier,
the ones who weren't immediately put off by having to learn a strange syntax.
There were fewer quotes to parse, fewer backslash escapes.
Anyway, since there are also people who dislike having to put up with strange
syntaxes, we'll call that consideration a wash and tear this DSL out.
---
This commit was sheer drudgery. Hopefully it won't need to be redone with
a new DSL because I grow sick of backslashes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Update the syntax documentation.
|
| | |
|
| |
|
|
| |
Check for duplicate docstrings.
|
| |
|
|
|
|
|
|
| |
Add the standard mnemonic for each opcode.
We aren't ever going to have complete docs of the subset of the x86 ISA
we support, so we need to help readers cross-correlate with the complete
docs.
|
| |
|
|
|
|
| |
It now includes details for 8-bit registers. And we'll just use the classic
names for the registers so that the relationships between 8- and 32-bit
versions are more obvious.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Detect overlapping segments when loading SubX source code.
This will start to become more of a risk as we start loading multiple files,
juggling multiple segments, etc.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Now simulated 'Memory' isn't just a single flat array. Instead it knows
about segments and VMAs.
The code segment will always be first, and the data/heap segment will always
be second. The brk() syscall knows about the data segment.
One nice side-effect is that I no longer need to mess with Memory initialization
regardless of where I place my segments.
|
| |
|
|
|
|
|
|
|
|
| |
Doesn't de-duplicate in the data segment, though. If you use the literal
"foo" a hundred times in your code segment you're gonna spend a hundred
times the space you need to.
We can now simplify our test harness a bit in the factorial app, but we
still have to put in commandline args to compare with manually. We only
support length-prefixed strings, not null-terminated ones.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
As we climb the ladder of abstraction we'll gradually pull the ladder up
behind ourselves.
|
| | |
|
| |
|
|
|
| |
It would be confusing to use negative numbers in raw hex. But we'll rely
on programmer taste there.
|
| |
|
|
|
|
| |
Hacky test. I'm creating a helper to run tests just for this layer. But
I won't be able to do this when I want to selectively run just
transforms below some level.
|
| | |
|
| |
|
|
| |
More tracing reorg.
|
| |
|
|
| |
Clean up trace levels everywhere in SubX.
|
| |
|
|
|
|
|
|
| |
Key core data structures by hex bytes in text rather than opcode
numbers. Saves us round trips of having to parse and reparse strings,
and also allows us to more easily ignore unexpected non-hex words in
each transform. We'll use this ability next when we start inserting
labels.
|
|
|
Better name for a layer.
|