about summary refs log tree commit diff stats
path: root/apps
Commit message (Collapse)AuthorAgeFilesLines
* 6153 - switch 'main' to use Mu stringsKartik Agaram2020-03-1515-7/+7
| | | | | | | | | | | At the SubX level we have to put up with null-terminated kernel strings for commandline args. But so far we haven't done much with them. Rather than try to support them we'll just convert them transparently to standard length-prefixed strings. In the process I realized that it's not quite right to treat the combination of argc and argv as an array of kernel strings. Argc counts the number of elements, whereas the length of an array is usually denominated in bytes.
* 6152 - fix regression in factorial.muKartik Agaram2020-03-152-2/+100
| | | | | I had to amend commit 6148 three times yesterday as I kept finding bugs by inspection. And yet I stubbornly thought I didn't need a test.
* 6150 - call-by-reference is workingKartik Agaram2020-03-142-0/+79
|
* 6149 - pass multi-word objects to functionsKartik Agaram2020-03-142-4/+103
| | | | This is quite inefficient; don't use it for very large objects.
* 6148Kartik Agaram2020-03-142-2/+42
|
* 6147Kartik Agaram2020-03-142-10/+10
|
* 6145 - 'address' operatorKartik Agaram2020-03-142-0/+74
| | | | | 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-141-4/+10
|
* 6143Kartik Agaram2020-03-142-6/+8
|
* 6139Kartik Agaram2020-03-121-1/+1
|
* 6138Kartik Agaram2020-03-121-0/+32
|
* 6133Kartik Agaram2020-03-122-3/+65
|
* 6132Kartik Agaram2020-03-122-30/+30
|
* 6131 - operating on arrays on the stackKartik Agaram2020-03-122-45/+299
|
* 6130Kartik Agaram2020-03-111-4/+3
|
* 6128 - arrays on the stackKartik Agaram2020-03-112-10/+145
|
* 6126 - support 8-byte register namesKartik Agaram2020-03-115-3/+3
| | | | 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-111-0/+0
| | | | | | | | | | | | | 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
|
* 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
|
* 6096Kartik Agaram2020-03-072-3/+58
| | | | A new test, and a new bugfix.
* 6095Kartik Agaram2020-03-071-0/+0
|
* 6094 - new 'compute-offset' instructionKartik Agaram2020-03-0713-23/+167
| | | | | | | | | | | | | | | | | | | | | | | 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.
* 6092Kartik Agaram2020-03-061-10/+10
|
* 6090 - new instruction: multiply by immediateKartik Agaram2020-03-062-0/+26
| | | | | | | | | | | | | | | This is a 3-operand instruction: r32 = rm32 * imm32 It looks like https://c9x.me/x86/html/file_module_x86_id_138.html has a bug, implying the same opcode supports a 2-operand version. I don't see that in the Intel manual pdf, or at alternative sites like https://www.felixcloutier.com/x86/imul Native runs seem to validate my understanding. In the process I also fixed a bug in the existing multiply instruction 0f af: the only flags it sets are OF and CF. The other existing multiply instruction f7 was doing things right.
* 6089Kartik Agaram2020-03-0628-70/+70
|
* 6088 - start using setCC instructionsKartik Agaram2020-03-064-20/+33
|
* 6086 - `index` into arrays with a literalKartik Agaram2020-03-062-30/+114
|