about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 6040Kartik Agaram2020-02-211-3/+20
|
* 6039Kartik Agaram2020-02-212-0/+22
|
* 6038Kartik Agaram2020-02-201-8112/+8313
|
* 6037 - first passing test for pointer lookupKartik Agaram2020-02-202-67/+192
|
* 6036Kartik Agaram2020-02-202-5/+6
|
* 6035Kartik Agaram2020-02-202-18/+18
|
* 6034Kartik Agaram2020-02-202-20/+20
|
* 6033 - save pointer lookup state while parsingKartik Agaram2020-02-202-30/+37
|
* 6032 - make room for '*' pointer lookups in stmtsKartik Agaram2020-02-202-31/+89
|
* 6031 - bugfix in selecting codegen patternKartik Agaram2020-02-202-6/+23
|
* 6030Kartik Agaram2020-02-202-11/+9
|
* 6029Kartik Agaram2020-02-202-4/+4
|
* 6028Kartik Agaram2020-02-201-4/+4
|
* 6027Kartik Agaram2020-02-201-1/+0
| | | | | | Changing `switchbuf` globally is too heavyweight a change just to do the right thing when hitting `:T`. I don't even use it anymore since I got `<Leader>t`; why was I hitting `:T` just to navigate to `last_run`, again?
* 6026Kartik Agaram2020-02-182-20/+20
|
* 6025Kartik Agaram2020-02-182-6715/+7029
|
* 6024 - finally, commandline parsing in MuKartik Agaram2020-02-181-4/+22
|
* 6023 - bug: vars with both stack-offset and regKartik Agaram2020-02-182-10/+20
| | | | | This was initially disquieting; was I writing enough tests? Then I noticed I had TODOs for some missing checks.
* 6022 - initial sketch of array lengthKartik Agaram2020-02-182-0/+75
| | | | | This is a particularly large abstraction leak: SubX arrays track their lengths in bytes, and therefore Mu as well.
* 6022Kartik Agaram2020-02-182-1/+4
| | | | Forgot to actually use the new type-dispatch in commit 6017.
* 6021Kartik Agaram2020-02-182-0/+22
|
* 6020Kartik Agaram2020-02-182-55/+47
| | | | Some deduplication, though this may be a premature abstraction.
* 6019 - finish supporting all branch primitivesKartik Agaram2020-02-184-10/+238
| | | | | | | | I'd been thinking I didn't need unconditional `break` instructions, but I just realized that non-local unconditional breaks have a use. Stop over-thinking this, just support everything. The code is quite duplicated.
* 6018Kartik Agaram2020-02-171-3935/+3975
|
* 6017 - simplify type-dispatch for primitivesKartik Agaram2020-02-172-26/+66
| | | | | | | | | | | | We'll be doing type-checking in a separate phase in future. For now we need only to distinguish between literals and non-literals for x86 primitive instructions. I was tempted to support x86 set__ instructions for this change: https://c9x.me/x86/html/file_module_x86_id_288.html That will happen at some point. And I'll simplify a bunch of branches for results of predicate functions when it happens.
* 6016Kartik Agaram2020-02-172-10/+10
|
* 6015Kartik Agaram2020-02-1727-236/+317
|
* 6014Kartik Agaram2020-02-1711-75/+75
|
* 6013Kartik Agaram2020-02-161-2/+2
|
* 6012Kartik Agaram2020-02-161-6330/+6264
|
* 6011Kartik Agaram2020-02-162-5/+3
|
* 6010 - starting to flesh out run-testsKartik Agaram2020-02-161-1/+1
|
* 6009 - significantly cleaner lexingKartik Agaram2020-02-163-135/+34
| | | | | | | | | This cleans up a bunch of little warts that had historically accumulated because of my bull-headedness in not designing a grammar up front. Let's see if the lack of a grammar comes up again. We now require that there be no space in variable declarations between the name and the colon separating it from its type.
* 6008Kartik Agaram2020-02-163-19/+20
| | | | | | | | Allow comments at the end of all kinds of statements. To do this I replaced all calls to next-word with next-mu-token.. except one. I'm not seeing any bugs yet, any places where comments break things. But this exception makes me nervous.
* 6007Kartik Agaram2020-02-141-2/+2
|
* 6006Kartik Agaram2020-02-142-4/+4
|
* 6005Kartik Agaram2020-02-143-4/+47
| | | | | | | | Support calling SubX code from Mu. I have _zero_ idea how to make this safe. Now we can start writing tests. We can't use commandline args yet. That requires support for kernel strings.
* 6004Kartik Agaram2020-02-141-0/+11
|
* 6003Kartik Agaram2020-02-092-7/+18
|
* 6002Kartik Agaram2020-02-091-3/+4
|
* 6001Kartik Agaram2020-02-0918-7154/+7393
|
* 6000 - clean up after no-local branchesKartik Agaram2020-02-0916-12/+215
|
* 5999Kartik Agaram2020-02-0911-1/+1
| | | | | Fix CI. apps/survey was running out of space in the trace segment when translating apps/mu.subx
* 5998 - redo code-generation for 'break'Kartik Agaram2020-02-092-77/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I've been saying that we can convert this: { var x: int break-if-= ... } ..into this: { 68/push 0/imm32 { 0f 84/jump-if-= break/disp32 ... } 81 0/subop/add %esp 4/imm32 } All subsequent instructions go into a nested block, so that they can be easily skipped without skipping the stack cleanup. However, I've been growing aware that this is a special case. Most of the time we can't use this trick: for loops for non-local breaks for non-local loops In most cases we need to figure out all the intervening variables on the stack and emit code to clean them up. And now it turns out even for local breaks like above, the trick doesn't work. Consider what happens when there's a loop later in the block: { var x: int break-if-= ... } If we emitted a nested block for the break, the local loop would become non-local. So we replace one kind of state with another. Easiest course of action is to just emit the exact same cleanup code for all conditional branches.
* 5997 - clean up after unconditional loopsKartik Agaram2020-02-092-34/+122
| | | | | | | Turns out we can't handle them like conditional loops. This function to emit cleanup code for jumps is getting quite terrible. I don't yet know what subsidiary abstractions it needs.
* 5996Kartik Agaram2020-02-091-0/+12
|
* 5995Kartik Agaram2020-02-081-7408/+7804
|
* 5994Kartik Agaram2020-02-081-3/+3
|
* 5993 - support for unlabeled loop instructionsKartik Agaram2020-02-082-3/+213
| | | | | Now that we have the infrastructure for emitting cleanup blocks, the labeled variants should be easy as well.
* 5992Kartik Agaram2020-02-072-12/+43
|