about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 6532 - arith: REPL converting ints to hexKartik Agaram2020-06-151-6/+18
| | | | | I'm using one character of lookahead, inspired by Crenshaw's "let's build a compiler".
* 6531Kartik Agaram2020-06-151-25/+17
|
* 6530Kartik Agaram2020-06-151-0/+40
| | | | | New prototype: a simple 4-operator calculator. Inspired (yet again) by Crenshaw.
* 6529 - don't let `addr`s escape functionsKartik Agaram2020-06-152-19/+24
| | | | | | | | | | | | | | | | | | I've gone back and forth on this. I initially disallowed this, then allowed it because I forgot why I disallowed it. The reason to disallow it: if you return an `addr` to a variable allocated on the stack, the space might be reused for a different type, which violates type-safety. And once you can reinterpret bits of one type as another you lose memory-safety as well. This has some interesting implications for Mu programs; certain kinds of helper functions become impossible to write. Now I find myself relying a lot more on scopes (and editor folding support) for abstracting details. And they won't help manage duplication. We'll see how this goes. While I'm being draconian about `addr`s on the stack, I'm still abusing `addr`s on the heap, with the expectation that future checks on reclamation will protect me. The boon and bane of stack space is that it's constantly reclaimed.
* 6528Kartik Agaram2020-06-1512-20/+147
|
* 6527 - increase stack limitsKartik Agaram2020-06-152-0/+6
| | | | | | We haven't run into this limit yet, but everytime I see a 'stream overflow' error I run into it while going over all the knobs in apps/subx-params.subx, if I increase Input-size (used by survey.subx) too much.
* 6526Kartik Agaram2020-06-151-1/+1
|
* 6525Kartik Agaram2020-06-152-11/+157
|
* 6524Kartik Agaram2020-06-152-7/+65
|
* 6523Kartik Agaram2020-06-152-0/+95
| | | | | Still some issues; add some tests. I have more that were passing a couple of days ago but aren't currently.
* 6522 - redo support for 'byte'Kartik Agaram2020-06-152-13/+81
| | | | | | | | | | | Before: bytes can't live on the stack, so size(byte) == 1 just for array elements. After: bytes mostly can't live on the stack except for function args (which seem too useful to disallow), so size(byte) == 4 except there's now a new primitive called element-size for array elements where size(byte) == 1. Now apps/browse.subx starts working again.
* 6521 - new primitive: array size in bytesKartik Agaram2020-06-142-0/+17
|
* 6520 - new app: parse-intKartik Agaram2020-06-1416-8/+290
| | | | | | Several bugs fixed in the process, and expectation of further bugs is growing. I'd somehow started assuming I don't need to have separate cases for rm32 as a register vs mem. That's not right. We might need more reg-reg Primitives.
* 6519Kartik Agaram2020-06-131-1/+47
| | | | More fucking amateur hour.
* 6518 - extra args through a whole swathe of placesKartik Agaram2020-06-132-7/+54
| | | | | | | | Most unbelievably, I'd forgotten to pass the output 'out' arg to 'lookup-var' long before the recent additions of 'err' and 'ed' args. But things continued to work because an earlier call just happened to leave the arg at just the right place on the stack. So we only caught all these places when we had to provide error messages.
* 6517Kartik Agaram2020-06-131-14034/+14335
|
* 6516 - operations on bytesKartik Agaram2020-06-134-11/+228
| | | | | | Byte-oriented addressing is only supported in a couple of instructions in SubX. As a result, variables of type 'byte' can't live on the stack, or in registers 'esi' and 'edi'.
* 6515 - error if 'get' on unknown fieldKartik Agaram2020-06-122-2/+117
| | | | We can't yet say in the error message precisely where the 'get' occurs.
* 6514Kartik Agaram2020-06-121-3/+3
|
* 6513Kartik Agaram2020-06-1267-25070/+25441
|
* 6512Kartik Agaram2020-06-121-14762/+14758
|
* 6511 - start of error-checkingKartik Agaram2020-06-122-17/+84
| | | | | We now raise an error if a variable is declared on the stack with an initializer. And there are unit tests for this functionality.
* 6510Kartik Agaram2020-06-118-8/+8
|
* 6509 - mu.subx: exit-descriptors everywhereKartik Agaram2020-06-112-323/+285
|
* 6508 - support null exit-descriptorKartik Agaram2020-06-1017-30/+19
|
* 6507 - use syscall names everywhereKartik Agaram2020-06-1054-213/+108
|
* 6506Kartik Agaram2020-06-101-3/+0
|
* 6505Kartik Agaram2020-06-091-1/+1
|
* 6504Kartik Agaram2020-06-081-0/+1
|
* 6503Kartik Agaram2020-06-083-12/+4
|
* 6502Kartik Agaram2020-06-073-14753/+15233
|
* 6501Kartik Agaram2020-06-072-2/+2
| | | | Bugfix in support for CRLF line-endings.
* 6500Kartik Agaram2020-06-073-174/+174
| | | | Minor formatting tweaks.
* 6499Kartik Agaram2020-06-071-2/+2
|
* 6498Kartik Agaram2020-06-062-116/+116
| | | | | Switch bullet lists in Markdown files away from `*`; it's ambiguous with emphasis.
* 6497Kartik Agaram2020-06-061-19/+29
|
* 6496Kartik Agaram2020-06-065-1/+474
|
* 6495Kartik Agaram2020-06-062-89/+91
|
* 6494Kartik Agaram2020-06-064-0/+471
|
* 6493 - browse: '#'s inside lines aren't headingsKartik Agaram2020-06-064-11/+18
|
* 6492Kartik Agaram2020-06-061-2/+0
|
* 6491Kartik Agaram2020-06-064-0/+466
|
* 6490 - browse: some manual testsKartik Agaram2020-06-062-0/+16293
|
* 6489 - browse app: headersKartik Agaram2020-06-062-2/+94
| | | | | Again quite ugly. There's an increasing amount of state here, particularly the interplay between headers and soft newlines.
* 6488Kartik Agaram2020-06-054-0/+377
|
* 6487 - browse: support soft newlinesKartik Agaram2020-06-053-6/+55
| | | | | I'm not bothering with this for bold regions just yet. Might need rethinking, given how ugly this is.
* 6486Kartik Agaram2020-06-054-0/+332
|
* 6485Kartik Agaram2020-06-051-5/+9
|
* 6484Kartik Agaram2020-06-051-16/+6
| | | | Ooh, it's nice and composable if we just never render the delimiters. Perfect.
* 6483 - finally, bold markup in the paginatorKartik Agaram2020-06-051-1/+75
| | | | | | The state machines are still not composing perfectly. The initial asterisk gets added in one, and the trailing asterisk in another. I suppose "always render the terminator" is fairly regular.