| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Still some issues; add some tests. I have more that were passing a couple
of days ago but aren't currently.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
More fucking amateur hour.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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'.
|
| |
|
|
| |
We can't yet say in the error message precisely where the 'get' occurs.
|
| |
|
|
|
| |
We now raise an error if a variable is declared on the stack with an initializer.
And there are unit tests for this functionality.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Fix a stray copy-paste when deciding whether to emit spills for registers
(commit 6464).
|
| |
|
|
|
|
|
| |
I had a little "optimization" to avoid creating nested blocks if "they weren't
needed". Except, of course, they were. Lose the optimization. Sometimes
we create multiple jumps when a single one would suffice. Ignore that for
now.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
The rule: emit spills for a register unless the output is written somewhere
in the current block after the current instruction. Including in nested
blocks.
Let's see if this is right.
|
| |
|
|
|
|
| |
Rather than have two ways to decide whether to emit push/pop instructions,
just record for each var on the 'vars' stack whether we emitted a push
for it, and reuse the decision to emit a pop.
|
| |
|
|
| |
Stack bug.
|
| | |
|