about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 6143Kartik Agaram2020-03-144-56/+60
|
* 6142Kartik Agaram2020-03-141-6/+9
|
* 6141Kartik Agaram2020-03-141-0/+12
|
* 6140Kartik Agaram2020-03-141-2/+1
|
* 6139Kartik Agaram2020-03-122-2/+2
|
* 6138Kartik Agaram2020-03-122-0/+126
|
* 6137Kartik Agaram2020-03-121-1/+2
|
* 6136 - ok, we can now call records and arrays doneKartik Agaram2020-03-121-4/+4
| | | | | | | | | Maybe not quite. One final issue: length is denominated in bytes, which is abstraction-busting and all, but dashed inconvenient. Unfortunately x86 doesn't have a divide instruction that takes an immediate :( So I'm not sure how to transparently perform the division without needing some extra register.
* 6135Kartik Agaram2020-03-121-9719/+10204
|
* 6134Kartik Agaram2020-03-121-1/+1
|
* 6133Kartik Agaram2020-03-122-3/+65
|
* 6132Kartik Agaram2020-03-122-30/+30
|
* 6131 - operating on arrays on the stackKartik Agaram2020-03-124-46/+306
|
* 6130Kartik Agaram2020-03-112-20/+18
|
* 6129Kartik Agaram2020-03-112-2/+5
|
* 6128 - arrays on the stackKartik Agaram2020-03-112-10/+145
|
* 6127Kartik Agaram2020-03-111-0/+11
|
* 6126 - support 8-byte register namesKartik Agaram2020-03-117-15/+26
| | | | Using these is quite unsafe. But what isn't, here?
* 6125Kartik Agaram2020-03-112-6/+15
|
* 6124Kartik Agaram2020-03-112-2/+8
|
* 6123 - runtime helper for initializing arraysKartik Agaram2020-03-114-0/+724
| | | | | | | | | | | | | I built this in 3 phases: a) create a helper in the bootstrap VM to render the state of the stack. b) interactively arrive at the right function (tools/stack_array.subx) c) pull the final solution into the standard library (093stack_allocate.subx) As the final layer says, this may not be the fastest approach for most (or indeed any) Mu programs. Perhaps it's better on balance for the compiler to just emit n/4 `push` instructions. (I'm sure this solution can be optimized further.)
* 6122Kartik Agaram2020-03-102-0/+44
|
* 6121Kartik Agaram2020-03-101-3/+3
|
* 6119Kartik Agaram2020-03-104-9522/+10225
|
* 6118 - support records on the stackKartik Agaram2020-03-102-12/+96
|
* 6117 - fix offset computationKartik Agaram2020-03-101-13/+15
| | | | | | It makes no sense to know where the next variable will start before I've seen it or how much space it needs. Things have only been working so far because all variables take 4 bytes.
* 6116 - stack locations now computed during codegenKartik Agaram2020-03-102-66/+91
| | | | | | | | | | | | | We can't do it during parsing time because we may not have all type definitions available yet. Mu supports using types before defining them. At first I thought I should do it in populate-mu-type-sizes (appropriately renamed). But there's enough complexity to tracking when stuff lands on the stack that it's easiest to do while emitting code. I don't think we need this information earlier in the compiler. If I'm right, it seems simpler to colocate the computation of state close to where it's used.
* 6115Kartik Agaram2020-03-102-27/+0
|
* 6114Kartik Agaram2020-03-101-2/+2
|
* 6113Kartik Agaram2020-03-102-58/+41
|
* 6112Kartik Agaram2020-03-082-21/+112
| | | | | Move computation of offsets to record fields into the new phase as well. Now we should be robust to type definitions in any order.
* 6111Kartik Agaram2020-03-082-5/+185
| | | | | | | | | | Move out total-size computation from parsing to a separate phase. I don't have any new tests yet, but it's encouraging that existing tests continue to pass. This may be the first time I've ever written this much machine code (with mutual recursion!) and gotten it to work the first time.
* 6110Kartik Agaram2020-03-081-2/+3
|
* 6109Kartik Agaram2020-03-082-2/+0
|
* 6108Kartik Agaram2020-03-082-13/+6
|
* 6107Kartik Agaram2020-03-082-2/+15
| | | | | Finally we're now able to track the index of a field in a record/struct/product type.
* 6106Kartik Agaram2020-03-082-9/+6
| | | | Free up eax using the newly available register.
* 6105Kartik Agaram2020-03-082-6/+9
| | | | Create space for another local.
* 6104Kartik Agaram2020-03-082-7/+12
| | | | | parse-mu-types has a lot of local state. Move a local to the stack to free up a register.
* 6103Kartik Agaram2020-03-082-3/+1
|
* 6102Kartik Agaram2020-03-081-26/+0
|
* 6101Kartik Agaram2020-03-082-45/+92
| | | | | | | | | Make room for additional information for each field in a record/product type. Fields can be used before they're declared, and we may not know the offsets they correspond to at that point. This is going to necessitate a lot of restructuring.
* 6100Kartik Agaram2020-03-081-2/+9
| | | | Fix a bug with a live register being clobbered.
* 6099Kartik Agaram2020-03-081-38/+5
|
* 6098Kartik Agaram2020-03-071-2/+2
| | | | | It was premature to say user-defined record types and array types were done.
* 6097Kartik Agaram2020-03-072-4/+1
| | | | | | I thought I needed to support compute-offset with literal index, but in that case might as well just use an index literal directly. The 'index' instruction with literals already supports non-power-of-2 sizes.
* 6096Kartik Agaram2020-03-072-3/+58
| | | | A new test, and a new bugfix.
* 6095Kartik Agaram2020-03-072-10/+10
|
* 6094 - new 'compute-offset' instructionKartik Agaram2020-03-0715-29/+186
| | | | | | | | | | | | | | | | | | | | | | | If indexing into a type with power-of-2-sized elements we can access them in one instruction: x/reg1: (addr int) <- index A/reg2: (addr array int), idx/reg3: int This translates to a single instruction because x86 instructions support an addressing mode with left-shifts. For non-powers-of-2, however, we need a multiply. To keep things type-safe, it is performed like this: x/reg1: (offset T) <- compute-offset A: (addr array T), idx: int y/reg2: (addr T) <- index A, x An offset is just an int that is guaranteed to be a multiple of size-of(T). Offsets can only be used in index instructions, and the types will eventually be required to line up. In the process, I have to expand Input-size because mu.subx is growing big.
* 6093Kartik Agaram2020-03-072-111/+168
| | | | Some much-needed reorganization.