about summary refs log tree commit diff stats
path: root/linux
Commit message (Collapse)AuthorAgeFilesLines
* obsolete argumentKartik K. Agaram2022-01-091-1/+1
|
* keep 'grapheme-stack'Kartik Agaram2021-11-093-80/+80
| | | | We want to at least document intent there.
* rename grapheme to code-point-utf8Kartik K. Agaram2021-11-0925-698/+698
| | | | | | Longer name, but it doesn't lie. We have no data structure right now for combining multiple code points. And it makes no sense for the notion of a grapheme to conflate its Unicode encoding.
* copy back some error messages from linux/Kartik K. Agaram2021-11-091-1/+1
|
* .Kartik K. Agaram2021-09-131-3/+5
|
* fix bad terminology: grapheme -> code pointKartik K. Agaram2021-08-291-5/+2
| | | | | | | | | | Unix text-mode terminals transparently support utf-8 these days, and so I treat utf-8 sequences (which I call graphemes in Mu) as fundamental. I then blindly carried over this state of affairs to bare-metal Mu, where it makes no sense. If you don't have a terminal handling font-rendering for you, fonts are most often indexed by code points and not utf-8 sequences.
* compute-offset: literal indexKartik K. Agaram2021-08-252-5/+130
|
* .Kartik K. Agaram2021-08-251-6/+6
|
* another long-overdue bugfixKartik K. Agaram2021-08-222-3/+87
| | | | | | | If I forgot a 'var', Mu would interpret the ':' in the var declaration as a named block, and all parsing after would be thrown off. Perhaps I should use separate characters for defining blocks vs vars.
* fix a long-standing bug in Mu's translatorKartik K. Agaram2021-08-222-0/+47
| | | | | | | | | | | | | | | | While all test pass, this change is disquieting. When I first designed Mu I deliberately chose to exclude literal strings from most primitive instructions both for type-checking and to avoid silently passing through strange constructions. Nobody really needs to add a string to a number, and am I sure no SubX instruction will cause a memory safety issue when passed a string literal instead of a number? But clearly I have no tests encoding this desire. And any string literal could be replaced by an integer literal containing the exact same value, so what are we protecting against anyway. Let me fix the bug for now. If I run into problems I'll come back and do this right.
* start throwing error on labels too far for /disp8Kartik K. Agaram2021-08-222-0/+70
| | | | | | | | | | | | | | | | | | | | | While I'm doing this I might as well lay out a story I don't seem to have told before in this commit log. I translated Mu programs to Linux before I did so to bare metal like I do in the top-level these days. The translator programs still run from the linux/ directory. However they don't always have good error messages. As long as I was translating to Linux this wasn't a huge deal because I always translated Mu programs using the bootstrap translator in linux/bootstrap/ -- which has great error messages. However, linux/bootstrap/ can't build bare-metal programs because boot.subx uses real-mode instructions that aren't supported. As a hack I created a script called misc_checks that at least tries to run everything besides boot.subx -- even though translation can never succeed. If I run it and get to errors about unknown variables I know everything besides boot.subx raised no errors. Having labels too far in /disp8 args is is the single biggest reason we need the misc_checks hack. Hopefully it's now obsolete.
* .Kartik K. Agaram2021-08-222-3/+4
|
* start throwing error on duplicate labelKartik K. Agaram2021-08-2223-72/+385
| | | | | | | | | | One less error that's only in the bootstrap phase. On the other hand, for simplicity I got rid of the ability to override the Entry label. One less special case, but we're also going further from the ability to run subsets of layers. We haven't really been exercising it for a long time, though (commit 7842, March 2021 when we made baremetal the default).
* .Kartik K. Agaram2021-08-222-16/+12
|
* support non-line-oriented processing in next-wordKartik K. Agaram2021-07-2913-11/+26
| | | | Immediately this simplifies support for comments in image data.
* .Kartik K. Agaram2021-07-203-46/+46
|
* .Kartik K. Agaram2021-07-2039-531/+94
|
* .Kartik K. Agaram2021-07-2018-41/+41
| | | | | Update run instructions for linux/app/ examples, and make sure they are correct.
* .Kartik K. Agaram2021-07-204-1346/+2
| | | | | Delete the examples from Crenshaw. They're extremely rudimentary, and they were really just trial runs for the Mu toolchain.
* start work on running the Mu toolchain atop MuKartik K. Agaram2021-07-1914-14/+14
|
* .Kartik K. Agaram2021-07-161-2/+2
|
* .Kartik K. Agaram2021-07-1665-71/+75
|
* .Kartik K. Agaram2021-06-271-0/+5
|
* .Kartik Agaram2021-06-151-1/+0
|
* .Kartik Agaram2021-06-151-0/+16
|
* .Kartik K. Agaram2021-06-151-1/+3
| | | | | Support newlines. Looks like we pasted the input from the browser window during the pairing session.
* example program by Sumeet AgarwalKartik K. Agaram2021-06-151-0/+48
| | | | | https://adventofcode.com/2017/day/1 https://archive.org/details/2021-06-02-akkartik-sumeet
* periodic run of misc_checksKartik K. Agaram2021-06-121-0/+1
| | | | | I should really stop using /disp8 jumps at the top-level given how inconvenient it is to check for overly large offsets.
* shell: expand set of possible errorsKartik K. Agaram2021-06-082-7/+55
| | | | | Requires a change to mu.subx, to unify literal strings with generic (addr array _)
* mu.subx: support bitwise notKartik K. Agaram2021-05-162-0/+51
|
* .Kartik K. Agaram2021-05-1414-66/+66
|
* free up '_' for top-level SubX functionsKartik K. Agaram2021-05-142-40/+40
|
* .Kartik K. Agaram2021-05-142-0/+1
|
* insert a compile phase to emit some debug infoKartik K. Agaram2021-05-146-2301/+2891
|
* .Kartik K. Agaram2021-05-142-53/+4
|
* .Kartik K. Agaram2021-05-142-0/+1
| | | | | Fix a stack bug in survey_baremetal. I'm not sure how my tests weren't crashing, but I won't bother digging further.
* .Kartik K. Agaram2021-05-142-5/+4
|
* .Kartik K. Agaram2021-05-141-3/+1
|
* .Kartik K. Agaram2021-05-092-31/+31
| | | | | Yet another step in the slow divergence of survey_baremetal from its survey_elf roots.
* support checking overflow flag everywhereKartik K. Agaram2021-05-086-9/+488
|
* always check for null in 'index' instructionsKartik K. Agaram2021-05-073-86/+120
|
* always check for null in 'get' instructionsKartik K. Agaram2021-05-073-13/+43
|
* opt: don't clear streams of bytes on the stackKartik K. Agaram2021-04-212-3/+152
| | | | | | | | | | | | All over the Mu code I reflexively initialize all variables just to keep unsafe SubX easy to debug. However I don't really need to do this for safe Mu code, since the type- and memory-safety already ensures we can't read from streams beyond what we've written to them. For now I'll continue mostly with the same approach, but with one exception for streams of bytes. Mu programs often emit traces, and in doing so they often use temporary streams of bytes that can get quite long. I'm hoping avoiding initializing KBs of data all over the place will measurably speed up the Mu shell.
* an interface approximating stack tracesKartik K. Agaram2021-04-202-0/+1
|
* undo previous commitKartik K. Agaram2021-04-052-3/+1
|
* snapshot: stupid debugging sessionKartik K. Agaram2021-04-052-1/+3
| | | | | | | | | | | | | | | I spent a while building a little keyboard scancode printer: $ ./translate ex1.mu && qemu-system-i386 disk.img ..and wondering why up-arrow was 0x48 in hex but 724 in decimal. I ended up paranoidly poking at a bunch of crap (though there _is_ a cool chromatography-based debugging technique in 126write-int-decimal.subx) before I realized: - 724 just has one extra digit over the correct answer - the 0xe0 scan code is a 3-digit number in decimal -- and the final digit is '4' There's nothing actually wrong.
* .Kartik Agaram2021-04-041-7/+9
|
* make online help more obviousKartik Agaram2021-04-041-0/+4
|
* some hacky checks for common errorsKartik K. Agaram2021-03-311-0/+4
| | | | | They're not really baked into the regular compilation process; I have to remember to run them if I see strange behavior.
* .Kartik Agaram2021-03-2938-98/+98
|