about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 5410 - 4 examples passingKartik Agaram2019-07-1718-13/+72
| | | | | Clean up other examples as well to satisfy the requirements in commit 5404.
* 5409Kartik Agaram2019-07-173-4/+16
| | | | | Bugfix eleven: segment flags were incorrectly computed. examples/ex1 now verified! Added to CI.
* 5408Kartik Agaram2019-07-1613-64/+418
| | | | | | | | | | | | Bugfix ten: type error in `convert`. I was calling `rewind-stream` on a `buffered-file`. examples/ex1 is now just one nibble off the canonical. I *have* found one missing feature in the self-hosted translator, though: dquotes doesn't support newlines in strings, even though the C++ version does. dquotes parses them right, but the value initialized in the data segment is wrong.
* 5407Kartik Agaram2019-07-152-0/+7
| | | | | | | Bugfix nine: flush(out) after translation is done. Still one remaining bug from comparing ELF binaries: emit-segments prints nothing for some reason.
* 5406Kartik Agaram2019-07-152-4/+4
| | | | | | | Bugfix eight: incorrect segment count in ELF header. The generated examples/ex1 is still not right. But it has the second segment now. Or almost all of it. Final byte is missing for some reason.
* 5405Kartik Agaram2019-07-154-14/+12
|
* 5404 - subx/examples/ex1 now translatingKartik Agaram2019-07-154-10/+47
| | | | | | | | | | | | | | | | | | | 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.
* 5403Kartik Agaram2019-07-141-3/+3
|
* update roadmap in subx/ReadmeKartik Agaram2019-07-141-7/+1
|
* .Kartik Agaram2019-07-1467-20762/+26544
|
* .Kartik Agaram2019-07-131-1/+0
|
* Merge pull request #34 from akkartik/surveyKartik Agaram2019-07-1353-2704/+9228
|\ | | | | SubX in SubX: computing addresses for labels
| * .Kartik Agaram2019-07-132-132/+132
| | | | | | | | Clean up.
| * add subx/apps/survey to CIKartik Agaram2019-07-131-0/+10
| |
| * .Kartik Agaram2019-07-133-0/+0
| |
| * survey.subx now passing all testsKartik Agaram2019-07-132-8/+34
| |
| * grow the output stream; test now completesKartik Agaram2019-07-131-2/+18
| | | | | | | | All assertions in `test-convert-computes-addresses` still failing.
| * `test-convert-computes-addresses` bugfix sixKartik Agaram2019-07-132-72/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | map of how far we've gotten by now (functions with '*' independently tested): ✓ compute-offsets* ✓ compute-addresses* ✓ emit-output ✓ emit-headers ✓ emit-elf-header ✓ emit-hex-array* ✓ first emit-elf-program-header-entry ✓ emit-hex-array* ? second emit-elf-program-header-entry emit-hex-array* emit-segments*
| * .Kartik Agaram2019-07-133-0/+0
| |
| * fixed fifth bug, hit sixthKartik Agaram2019-07-132-5/+6
| |
| * .Kartik Agaram2019-07-132-170/+0
| | | | | | | | Clean up.
| * fixed fourth bug, hit fifthKartik Agaram2019-07-132-50/+289
| |
| * fixed third bug, hit fourthKartik Agaram2019-07-131-1/+1
| |
| * .Kartik Agaram2019-07-132-190/+0
| | | | | | | | Clean up.
| * fixed second bug, hit thirdKartik Agaram2019-07-133-6/+293
| |
| * .Kartik Agaram2019-07-133-41/+39
| |
| * fixed one bug, hit anotherKartik Agaram2019-07-122-58/+87
| | | | | | | | | | | | | | | | | | | | I carefully logged the segment a label is declared in but forgot to actually save it in the table. This has been a theoretic concern for some time, but I've never seen it actually happen until now. SubX is just too low level. Now I get past the first two phases but code generation fails to find the 'Entry' label.
| * .Kartik Agaram2019-07-122-2/+70
| | | | | | | | | | | | | | | | Snapshot at a random moment, showing a new debugging trick: hacking on the C++ level to dump memory contents on specific labels. For some reason label 'x' doesn't have a segment assigned by the time we get to compute-addresses.
| * .Kartik Agaram2019-07-122-4/+44
| | | | | | | | | | | | | | Continuation of commit 6f6d458fcd to support unsigned comparisons in 32-bit jumps. Once again, no tests.
| * .Kartik Agaram2019-07-121-6/+6
| |
| * .Kartik Agaram2019-07-121-25/+25
| |
| * compute-offsets test now passingKartik Agaram2019-07-122-49/+97
| | | | | | | | The final integration test-convert-computes-addresses is still failing.
| * the pseudocode is pretty long, so add an outlineKartik Agaram2019-07-121-2/+11
| |
| * rearrange compute-offsets casesKartik Agaram2019-07-121-73/+74
| | | | | | | | | | Now they're in the order you expect to see them at runtime: first you see a segment header, then you see labels.
| * .Kartik Agaram2019-07-121-26/+26
| | | | | | | | move trace dump to before checks
| * .Kartik Agaram2019-07-111-1/+0
| |
| * one failure remaining in test-compute-offsetsKartik Agaram2019-07-112-123/+291
| | | | | | | | | | | | | | | | | | 'curr-segment-name' is now a string, and it's stored in a register rather than a global. Paradoxically, this leaks *less* than before. Before, every call to `get-or-insert-slice` leaked memory. Now we leak one string for every new segment. Which is trivial.
| * .Kartik Agaram2019-07-111-12/+12
| |
| * .Kartik Agaram2019-07-111-7/+5
| | | | | | | | | | Pseudocode is a little more truthful now about what variables are on the stack.
| * the problem: curr-segment-name is staleKartik Agaram2019-07-111-3/+126
| | | | | | | | | | | | | | It's a slice into the 'line' stream. But we want to preserve the current segment name across lines. Let's leak some memory.
| * .Kartik Agaram2019-07-111-14/+14
| | | | | | | | Make the trace a little more consistent.
| * label offset computation still has a bugKartik Agaram2019-07-111-6/+7
| | | | | | | | | | | | I changed the test a little to make it obvious. Basically there's no way we can compute the segment offset correctly without knowing the segment name in the previous assertion.
| * revert compute-offsets to segment-relative offsetsKartik Agaram2019-07-111-7/+7
| | | | | | | | | | | | | | | | The pseudocode was a mess here :/ I was saving the segment-offset but tracing the file-offset. Segments need file offsets (to tweak their starting address). Labels need segment offsets (to add to segment starting address).
| * .Kartik Agaram2019-07-111-2/+3
| |
| * move discard instruction to correct spotnc2019-07-111-2/+2
| |
| * updated test so 'x' is relative to file-offset not segment offsetnc2019-07-111-3/+3
| |
| * made test 2 passnc2019-07-111-9/+11
| |
| * .Kartik Agaram2019-07-102-3/+7
| |
| * .Kartik Agaram2019-07-101-7/+7
| |
| * .Kartik Agaram2019-07-101-0/+2
| |
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-12-14 00:03:19 +0000