about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 6178Kartik Agaram2020-03-318-8/+40
|
* 6177Kartik Agaram2020-03-291-4/+1
|
* 6176Kartik Agaram2020-03-291-6/+6
|
* 6175 - syntax highlighting for dteKartik Agaram2020-03-292-0/+72
| | | | https://gitlab.com/craigbarnes/dte
* 6174Kartik Agaram2020-03-271-1/+1
|
* 6173Kartik Agaram2020-03-272-10/+24
|
* 6172Kartik Agaram2020-03-261-1/+1
| | | | Typo in stats: use the same measures as in previous lines.
* 6171Kartik Agaram2020-03-251-2/+2
|
* 6170Kartik Agaram2020-03-252-6/+6
|
* 6169Kartik Agaram2020-03-252-2/+2
|
* 6168Kartik Agaram2020-03-251-1/+1
|
* 6167Kartik Agaram2020-03-251-1/+1
|
* 6166Kartik Agaram2020-03-251-2/+2
|
* 6165Kartik Agaram2020-03-251-10/+10
|
* 6164Kartik Agaram2020-03-242-93/+93
|
* 6163Kartik Agaram2020-03-231-0/+248
|
* 6162Kartik Agaram2020-03-237-36/+45
|
* 6161Kartik Agaram2020-03-221-2/+2
|
* 6160 - plan for safe heap accessKartik Agaram2020-03-212-2/+55
| | | | | | | | | Based on apps/handle.subx (commit 4894), but we're able to simplify it further now that we know more about the situation we find ourselves in. 6 instructions, zero pushes or pops. Before I can start building this, I need to reorganize my use of handles. They're going to be fat pointers so we can't store them in registers anymore.
* 6159Kartik Agaram2020-03-211-218/+165
|
* 6158 - standardize opcode namesKartik Agaram2020-03-215-107/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the lowest level, SubX without syntax sugar uses names without prepositions. For example, 01 and 03 are both called 'add', irrespective of source and destination operand. Horizontal space is at a premium, and we rely on the comments at the end of each line to fully describe what is happening. Above that, however, we standardize on a slightly different naming convention across: a) SubX with syntax sugar, b) Mu, and c) the SubX code that the Mu compiler emits. Conventions, in brief: - by default, the source is on the left and destination on the right. e.g. add %eax, 1/r32/ecx ("add eax to ecx") - prepositions reverse the direction. e.g. add-to %eax, 1/r32/ecx ("add ecx to eax") subtract-from %eax, 1/r32/ecx ("subtract ecx from eax") - by default, comparisons are left to right while 'compare<-' reverses. Before, I was sometimes swapping args to make the operation more obvious, but that would complicate the code-generation of the Mu compiler, and it's nice to be able to read the output of the compiler just like hand-written code. One place where SubX differs from Mu: copy opcodes are called '<-' and '->'. Hopefully that fits with the spirit of Mu rather than the letter of the 'copy' and 'copy-to' instructions.
* 6157Kartik Agaram2020-03-212-247/+41
|
* 6156Kartik Agaram2020-03-211-11/+0
|
* 6155Kartik Agaram2020-03-201-1/+3
|
* 6154 - include link to the Mu paperKartik Agaram2020-03-161-1/+1
|
* 6153 - switch 'main' to use Mu stringsKartik Agaram2020-03-1519-18/+170
| | | | | | | | | | | 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.
* 6151Kartik Agaram2020-03-151-2/+6
|
* 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
|
* 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
|