about summary refs log tree commit diff stats
path: root/subx/apps
Commit message (Collapse)AuthorAgeFilesLines
* 4988Kartik Agaram2019-02-256-0/+0
|
* 4983Kartik Agaram2019-02-223-39/+39
| | | | | | | 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.
* 4981 - no, go back to 3 phasesKartik Agaram2019-02-1813-49/+17
| | | | | | | | | | | | | 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.
* 4978 - maybe we need another phaseKartik Agaram2019-02-171-0/+36
| | | | | | | | | | | | | | 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.
* 4975 - new plan for Phase 2Kartik Agaram2019-02-161-4/+36
| | | | | | 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.
* 4973Kartik Agaram2019-02-154-29/+29
| | | | | Support immediate operands in the data segment in all the ways we support them in the code segment.
* 4969Kartik Agaram2019-02-151-2/+2
|
* 4968Kartik Agaram2019-02-146-0/+0
|
* 4966Kartik Agaram2019-02-142-12/+10
| | | | Standardize how we show register allocation decisions.
* 4965Kartik Agaram2019-02-146-0/+0
|
* 4961Kartik Agaram2019-02-1411-48/+48
|
* 4960Kartik Agaram2019-02-132-8/+6
| | | | | I think I don't need to special-case packing for different segments. That should massively cut down on the number of tests.
* 4956Kartik Agaram2019-02-112-1/+69
|
* 4955Kartik Agaram2019-02-107-20/+373
| | | | Starting to build up Phase 2 (apps/pack) out of recently designed primitives.
* 4954Kartik Agaram2019-02-106-0/+0
|
* 4952Kartik Agaram2019-02-056-0/+0
|
* 4951Kartik Agaram2019-02-036-0/+0
| | | | Cleaner way to compare streams in tests.
* 4949Kartik Agaram2019-02-026-0/+0
|
* 4948Kartik Agaram2019-02-022-6/+341
| | | | | This seems like the final helper we need for Phase 2. Now to build the business logic itself.
* 4947Kartik Agaram2019-02-012-0/+2
| | | | | | | | 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.
* 4946Kartik Agaram2019-02-012-2/+66
|
* 4945Kartik Agaram2019-02-016-0/+0
|
* 4943Kartik Agaram2019-01-301-1/+0
|
* 4939Kartik Agaram2019-01-212-3/+243
|
* 4938Kartik Agaram2019-01-206-8/+26
|
* 4937Kartik Agaram2019-01-206-4/+21
|
* 4935Kartik Agaram2019-01-161-2/+2
|
* 4934Kartik Agaram2019-01-162-2/+2
|
* 4933Kartik Agaram2019-01-165-5/+5
|
* 4931Kartik Agaram2019-01-161-1/+0
|
* 4930Kartik Agaram2019-01-156-1/+230
|
* 4929Kartik Agaram2019-01-156-6/+6
| | | | Clean up primitives for converting from/to hex chars.
* 4928Kartik Agaram2019-01-145-0/+0
|
* 4927Kartik Agaram2019-01-146-12/+13
|
* 4926Kartik Agaram2019-01-145-0/+0
|
* 4925Kartik Agaram2019-01-146-4/+4
|
* 4923Kartik Agaram2019-01-125-0/+0
| | | | | We want slice-equal? for length-prefixed strings, not null-terminated "kernel" strings.
* 4920Kartik Agaram2019-01-117-178/+4
|
* 4916Kartik Agaram2019-01-107-9/+0
| | | | | In the process of building slice primitives I found an out-of-bounds access in write-byte.
* 4915Kartik Agaram2019-01-081-11/+176
| | | | | | In the process of building next-token I finally added some support for a debugging situation I've found myself in a couple of times: wondering "what changed this memory location"?
* 4913Kartik Agaram2019-01-076-2/+22
|
* 4911Kartik Agaram2019-01-066-1/+0
|
* 4908Kartik Agaram2019-01-055-0/+0
| | | | | | | | Fix CI. a) Update canonical binaries. b) Fix an out-of-bounds access in `clear-stream`. This also required supporting a new instruction in `subx run` to load an imm8 into rm8.
* 4905 - safe ptr lookup is now 6 instructionsKartik Agaram2019-01-042-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.
* 4904Kartik Agaram2019-01-041-1/+0
|
* 4902 - initial sketch, stage 2 of compilerKartik Agaram2019-01-031-0/+164
| | | | I've agonized over this for a week; high time I saved a snapshot.
* 4900Kartik Agaram2018-12-302-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.
* 4896Kartik Agaram2018-12-301-0/+0
| | | | Fix CI.
* 4894Kartik Agaram2018-12-302-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.
* 4893Kartik Agaram2018-12-301-1/+1
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-12-02 16:06:36 +0000