| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
We want to at least document intent there.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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).
|
| | |
|
| |
|
|
| |
Immediately this simplifies support for comments in image data.
|
| | |
|
| | |
|
| |
|
|
|
| |
Update run instructions for linux/app/ examples, and make sure they are
correct.
|
| |
|
|
|
| |
Delete the examples from Crenshaw. They're extremely rudimentary, and
they were really just trial runs for the Mu toolchain.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Support newlines. Looks like we pasted the input from the browser window
during the pairing session.
|
| |
|
|
|
| |
https://adventofcode.com/2017/day/1
https://archive.org/details/2021-06-02-akkartik-sumeet
|
| |
|
|
|
| |
I should really stop using /disp8 jumps at the top-level given how inconvenient
it is to check for overly large offsets.
|
| |
|
|
|
| |
Requires a change to mu.subx, to unify literal strings with generic
(addr array _)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Fix a stack bug in survey_baremetal. I'm not sure how my tests weren't
crashing, but I won't bother digging further.
|
| | |
|
| | |
|
| |
|
|
|
| |
Yet another step in the slow divergence of survey_baremetal from its survey_elf
roots.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
They're not really baked into the regular compilation process; I have to
remember to run them if I see strange behavior.
|
| | |
|
| | |
|