| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
| |
Small change to mu.subx to keep the treeshaker working with it. That's
currently the only place where we prevent jumps across 'functions'.
|
| | |
|
| |
|
|
|
| |
All tests now passing, and factorial.mu and all other apps now working.
The new checks caught one problem in a few prototypes.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
I need to pass the function around to fix the failing test; might as well
fix the error messages while I'm at it.
|
| |
|
|
|
| |
https://github.com/tmux/tmux/wiki/Control-Mode
https://www.iterm2.com/documentation-tmux-integration.html
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
The desire captured by a test is often hard to verbalize, path-dependent
and more fertile for the future than its original impulse. On some level,
someone wanting to rip out features has to just ask for each scenario,
"what do I want to happen here?" And nobody's gonna do that. At best, somebody
may be trying to rip out some complex feature, and run into some collateral
damage around the edges that they have to inspect more closely. "Do I care
about preserving this behavior?"
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new failing test is now passing, and so is this manual test that had
been throwing a spurious error:
fn foo {
var a/eax: int <- copy 0
var b/ebx: int <- copy 0
{
var a1/eax: int <- copy 0
var b1/ebx: int <- copy a1
}
b <- copy a
}
However, factorial.mu is still throwing a spurious error.
Some history on this commit's fix: When I moved stack-location tracking
out of the parsing phase (commit 6116, Mar 10) I thoughtlessly moved block-depth
tracking as well. And the reason that happened: I'd somehow gotten by without
ever cleaning up vars from a block during parsing. For all my tests, this
is a troubling sign that I'm not testing enough.
The good news: clean-up-blocks works perfectly during parsing.
|
| |
|
|
|
| |
Test `test-shadow-name-2` shows that we aren't popping off more than one
variable from each block that we exit.
|
| | |
|
| | |
|
| |
|
|
| |
I'm still tracking down at least one bug in how that stack is managed.
|
| |
|
|
|
|
|
|
|
| |
I was shifting bitfields around based on their width rather than the width
of the field to their right.
Kinda shocking that I haven't used the scale bits until now. I've been
generating code that uses them in mu.subx tests, but apparently I haven't
actually _run_ any such code before.
|
| |
|
|
|
| |
Now all tests passing again. In the process I found a bug where one of
my tests actually generated incorrect code.
|
| |
|
|
|
|
|
|
|
|
| |
Defining a new var in a register based on a previous var in the same register.
Unfortunately I don't yet support such an instruction without getting into
arrays. Ideally I want `y <- add x, 1` to convert to the same code as `x
<- add x, 1` if `y` ends up in the same register. And so on. But I don't
yet have a way to specify "output same register as inout 1" in my `Primitives`
data structure.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When looking up a var, ensure that it's the var most recently written to
its register.
The new test passes, but a handful of tests now start failing when a new
var in register X is initialized based on the old var in register X. The
way we do lookups is not quite right. At the moment we perform lookups
when we parse words. So we look up outputs of a statement before inputs.
But old bindings are still valid for the entirety of a statement, and outputs
should only take effect for the next statement.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
There were a couple of benign type errors in arith.mu but nowhere else.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Ok, I think I'm done with this app for now.
|
| | |
|
| |
|
|
| |
I forgot that Mu doesn't have div yet.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Cleaner way to handle EOF.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
I'm using one character of lookahead, inspired by Crenshaw's "let's build
a compiler".
|
| | |
|
| |
|
|
|
| |
New prototype: a simple 4-operator calculator. Inspired (yet again) by
Crenshaw.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|