about summary refs log tree commit diff stats
path: root/subx/apps/handle.subx
Commit message (Collapse)AuthorAgeFilesLines
* 5059Kartik Agaram2019-04-051-1/+1
|
* 4981 - no, go back to 3 phasesKartik Agaram2019-02-181-6/+1
| | | | | | | | | | | | | 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.
* 4973Kartik Agaram2019-02-151-1/+1
| | | | | Support immediate operands in the data segment in all the ways we support them in the code segment.
* 4905 - safe ptr lookup is now 6 instructionsKartik Agaram2019-01-041-25/+20
| | | | | | | | | | | | | The lines within '{}' can now be turned into a macro like `E_X = deref(E_X)`, parameterizing the register being modified. Assumes the input is in a register but also saved elsewhere, so it's safe to clobber and replace with the result. Compare commit 4894. Used to take 9 instructions, 8 of them making loads/stores. Now it's 6 instructions, 4 of them loads/stores (the one non-local load is unchanged, of course). Key is to not consume more registers so we don't have to push/pop them.
* 4900Kartik Agaram2018-12-301-39/+34
| | | | | | | | | | | Finally really fix the CI failure of commit 4894. This is a remainder to forget my knowledge of stack addresses in the SubX VM when writing SubX programs. Otherwise my programs will work in the VM but not natively. The only assumptions a SubX program should make about its segment addresses are what's encoded in the ELF binary. Thanks to https://en.wikipedia.org/wiki/Address_space_layout_randomization, it can't know anything else.
* 4894Kartik Agaram2018-12-301-0/+160
| | | | | | | | | | | | Done with kinda-safe pointers. In a real compiler the fast path of 'lookup' would ideally get inlined. Excluding procedure-call overhead, the current implementation consumes 2 registers besides the input, and requires 9 instructions (2 push, 2 load, compare, jump, increment, 2 pop). That's large enough that inlining may become a trade-off. Even if we somehow magically had the registers already loaded and available, we'd still need 4 instructions (1 pointer dereference, compare, jump and increment). The price of safety.
* 4889 - playing with kinda-safe pointersKartik Agaram2018-12-291-0/+211