about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* .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
|
* .Kartik Agaram2019-07-102-2/+2
| | | | I think we're calling the wrong variant here.
* start distinguishing table lookups from insertsKartik Agaram2019-07-106-12/+382
|
* zero out new rows returned by get-or-insertKartik Agaram2019-07-1011-0/+103
|
* finally tracked down binary character in tracesKartik Agaram2019-07-101-1/+1
| | | | This was why grep required the `-a` argument in vimrc.vim.
* .Kartik Agaram2019-07-107-5/+5
| | | | | Another batch of incorrectly signed conditional jumps. (Follow-up to commit 5180.)
* .Kartik Agaram2019-07-102-1/+1
| | | | Fix infinite loop in the 2 remaining failing tests; now it's a segfault.
* .Kartik Agaram2019-07-102-8/+5
|
* .Kartik Agaram2019-07-091-37/+69
|
* mostly done with emit-outputKartik Agaram2019-07-096-6/+267
| | | | | Some nooks and crannies will need light final debugging with xxd, but emit-hex-output covers most of the logic.
* done with emit-segmentsKartik Agaram2019-07-092-33/+532
| | | | Only failures now are the first two tests in survey.subx.
* bug: null address messing up instruction decodeKartik Agaram2019-07-091-2/+7
| | | | Leads to a bad error message.
* .Kartik Agaram2019-07-092-7/+1
| | | | | | Stop dumping huge traces on error. We can always rerun with --trace. Though perhaps we should just dump the trace automatically on error. Not bothering thinking about that right now.
* .Kartik Agaram2019-07-091-26/+26
|
* .Kartik Agaram2019-07-091-0/+1
|
* .Kartik Agaram2019-07-091-2/+2
|
* .Kartik Agaram2019-07-091-1/+1
|
* clean up after a few callsKartik Agaram2019-07-092-4/+9
|
* preserve truthiness of non-booleansKartik Agaram2019-07-092-16/+12
| | | | | Everywhere we check if something is true, we check it by comparing against 0, not 1.
* this looks like a bugKartik Agaram2019-07-092-1/+1
| | | | | But of course the test is still infinite-looping so we can't be sure. I'm still just reading the code.
* .Kartik Agaram2019-07-092-15/+4
|
* .Kartik Agaram2019-07-091-19/+17
|
* move 'segment-start' to a global variable as wellKartik Agaram2019-07-092-12/+10
| | | | | It's ugly to have function locals in global variables, but we'll figure out later how to deal with it.
* .Kartik Agaram2019-07-091-8/+0
|
* there's a variant of compute-width for slicesKartik Agaram2019-07-091-9/+5
| | | | | Looks like the original compute-width is now dead. But still seems useful to have around.
* there's a variant of get-or-insert for slicesKartik Agaram2019-07-092-27/+16
| | | | | | The compute-offsets test now goes into an infinite loop :( But I figure all these changes are useful anyway, we should just debug the error separately.
* keep labels definitions on a separate lineKartik Agaram2019-07-091-6/+12
| | | | SubX in SubX doesn't support mixing labels with other stuff :)
* switch to global HeapKartik Agaram2019-07-092-10/+5
|
* update library docsKartik Agaram2019-07-091-5/+13
|
* .Kartik Agaram2019-07-088-88/+88
| | | | | Be more consistent about names of ends of a slice. (In the opposite direction compared to last night's 925fc490d2ce8b8d411de87bd0af5b3a8a704213.)