about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* 5991Kartik Agaram2020-02-072-1/+4
|
* 5990Kartik Agaram2020-02-061-1/+1
|
* 5989Kartik Agaram2020-02-062-17/+28
| | | | | | Start pushing dummy vars for labels on the stack as we encounter them. This won't affect cleanup code, but will make it easy to ensure that jumps are well-structured.
* 5988Kartik Agaram2020-02-062-41/+17
| | | | | | | Clean up data structures and eliminate the notion of named blocks. Named blocks still exist in the Mu language. But they get parsed into a uniform block data structure, same as unamed blocks.
* 5987Kartik Agaram2020-02-062-7/+7
|
* 5986Kartik Agaram2020-02-062-43/+1
|
* 5985Kartik Agaram2020-02-062-40/+30
| | | | | Standardize on a single block name. This simplifies some code and will also help in the next couple of steps.
* 5984 - start labeling all blocksKartik Agaram2020-02-052-165/+289
| | | | | | | | This will come in handy for the remaining cases where we need to clean up locals on the stack: loop after var non-local break with vars in intervening blocks non-local loop with vars in intervening blocks
* 5983 - fix an emulator bounds-check bugKartik Agaram2020-02-055-7/+7
| | | | | | It was possible for an instruction to write out of bounds of the memory data structure. Most of the time this worked fine. However if the block ever got resized and moved the out-of-bounds bytes no longer went along.
* 5982 - start putting block labels on the var stackKartik Agaram2020-02-052-26/+41
| | | | | | | | | | | | | | | | | | | | | Before: we detected labels using a '$' at the start of an arg, and turned them into literals. After: we put labels on the var stack and let the regular lookup of the var stack handle labels. This adds complexity in one place and removes it from another. The crucial benefit is that it allows us to store a block depth for each label. That will come in handy later. All this works only because of a salubrious coincidence: Mu labels are always at the start of a block, and jumps always refer to the name at the start of a block, even when the jump is in the forwards direction. So we never see label uses before definitions. Note on CI: this currently only works natively, not emulated.
* 5981 - decompose block cleanup into two traversalsKartik Agaram2020-02-022-35/+113
| | | | | Momentarily less efficient, but we will soon need the ability to emit cleanup code without losing all our state.
* 5980Kartik Agaram2020-02-021-3/+3
|
* 5979Kartik Agaram2020-02-021-2/+3
| | | | | | | Continuing to think about how to translate vars in a block when they're followed by early exits. To clean up everything between a statement and a target label, we need to know somehow the depth the target is defined at.
* 5978Kartik Agaram2020-02-021-1/+4
|
* 5977Kartik Agaram2020-02-022-4/+5
|
* 5976Kartik Agaram2020-02-021-3/+3
|
* 5975Kartik Agaram2020-02-021-7427/+7137
|
* 5974 - support for simple early exitsKartik Agaram2020-02-022-1/+84
| | | | | | | | | | | | | | | So far we only handle unlabeled break instructions correctly. That part is elegance itself. But the rest will need more work: a) For labeled breaks we need to insert code to unwind all intervening blocks. b) For unlabeled loops we need to insert code to unwind the current block and then loop. c) For labeled loops we need to insert code to unwind all intervening blocks and then loop. Is this even worth doing? I think so. It's pretty common for a conditional block inside a loop to 'continue'. That requires looping to somewhere non-local.
* 5973Kartik Agaram2020-02-021-369/+1
|
* 5972Kartik Agaram2020-02-011-6480/+6703
|
* 5971 - emit code with indentationKartik Agaram2020-02-012-256/+309
| | | | This is easy now that we're tracking block depths everywhere.
* 5970 - support block-scoped variablesKartik Agaram2020-02-012-6/+186
|