about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 6148Kartik Agaram2020-03-142-2/+42
|
* 6147Kartik Agaram2020-03-142-10/+10
|
* 6146Kartik Agaram2020-03-141-8975/+9044
|
* 6145 - 'address' operatorKartik Agaram2020-03-144-2/+85
| | | | | This could be a can of worms, but I think I have a set of checks that will keep use of addresses type-safe.
* 6144Kartik Agaram2020-03-142-54/+66
|
* 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.