| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Testing conversion of multiple lines in a data segment.
Bugs fixed:
1. Stack issues in next-token helpers.
2. Needed to teach next-token to avoid newlines.
3. rewind-stream(line) before passing it to convert-code or convert-instruction.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several bugs found after performing multiple loops through convert-data.
This has been a general pattern: given how unsafe the x86 'language' is,
the regular amount of testing with a single input doesn't really give sufficient
confidence. Ever-present is the possibility that I forgot to pop something
from the stack, either a spilled register or a local. Calling functions
multiple times seems to help detect such bugs. So far I've been doing this
extra level of testing implicitly when I build the next higher abstraction.
But with `convert-data` the buck stopped, and much painful debugging ensued.
One thing that would help is if `write` on streams didn't remain silent
on overflow. But we actually need that sometimes, when streams are used
as buffers.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Add a bounds-check to `next-word`.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Fix CI. pack.subx was passing in emulation but not natively.
Commit 4954 on Feb 10 was a real dud. First I find I forgot to reclaim
space for locals (commit 4996). Now I find I haven't been tracking registers
properly either.
|
|
|
|
|
|
|
|
|
| |
Yet another redrawing of responsibilities between convert and its helpers.
In the process I discovered a bug in `write-stream-buffered` which ended
up taking me through a detour to extract `browse_trace` into its own tool.
It turns out just having long buffers is enough to need browse_trace. Simple
operations like clearing a stream swamp a flat view of the trace.
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Support immediate operands in the data segment in all the ways we support
them in the code segment.
|
| |
|
| |
|
|
|
|
| |
Standardize how we show register allocation decisions.
|
| |
|
| |
|
|
|
|
|
| |
I think I don't need to special-case packing for different segments. That
should massively cut down on the number of 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.
|
| |
|
| |
|