| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
And we're using it now in factorial.mu!
In the process I had to fix a couple of bugs in pointer dereferencing.
There are still some limitations:
a) Indexing by a literal doesn't work yet.
b) Only arrays of ints supported so far.
Looking ahead, I'm not sure how I can support indexing arrays by non-literals
(variables in registers) unless the element size is a power of 2.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This was initially disquieting; was I writing enough tests? Then I noticed
I had TODOs for some missing checks.
|
| |
|
|
|
| |
This is a particularly large abstraction leak: SubX arrays track their
lengths in bytes, and therefore Mu as well.
|
| |
|
|
| |
Forgot to actually use the new type-dispatch in commit 6017.
|
| | |
|
| |
|
|
| |
Some deduplication, though this may be a premature abstraction.
|
| |
|
|
|
|
|
|
| |
I'd been thinking I didn't need unconditional `break` instructions, but
I just realized that non-local unconditional breaks have a use. Stop over-thinking
this, just support everything.
The code is quite duplicated.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We'll be doing type-checking in a separate phase in future. For now we
need only to distinguish between literals and non-literals for x86 primitive
instructions.
I was tempted to support x86 set__ instructions for this change:
https://c9x.me/x86/html/file_module_x86_id_288.html
That will happen at some point. And I'll simplify a bunch of branches for
results of predicate functions when it happens.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This cleans up a bunch of little warts that had historically accumulated
because of my bull-headedness in not designing a grammar up front. Let's
see if the lack of a grammar comes up again.
We now require that there be no space in variable declarations between
the name and the colon separating it from its type.
|
| |
|
|
|
|
|
|
| |
Allow comments at the end of all kinds of statements.
To do this I replaced all calls to next-word with next-mu-token.. except
one. I'm not seeing any bugs yet, any places where comments break things.
But this exception makes me nervous.
|
| | |
|
| |
|
|
|
|
|
|
| |
Support calling SubX code from Mu. I have _zero_ idea how to make this
safe.
Now we can start writing tests. We can't use commandline args yet. That
requires support for kernel strings.
|
| | |
|
| | |
|
| |
|
|
|
| |
Fix CI. apps/survey was running out of space in the trace segment when
translating apps/mu.subx
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've been saying that we can convert this:
{
var x: int
break-if-=
...
}
..into this:
{
68/push 0/imm32
{
0f 84/jump-if-= break/disp32
...
}
81 0/subop/add %esp 4/imm32
}
All subsequent instructions go into a nested block, so that they can be
easily skipped without skipping the stack cleanup.
However, I've been growing aware that this is a special case. Most of the
time we can't use this trick:
for loops
for non-local breaks
for non-local loops
In most cases we need to figure out all the intervening variables on the
stack and emit code to clean them up.
And now it turns out even for local breaks like above, the trick doesn't
work. Consider what happens when there's a loop later in the block:
{
var x: int
break-if-=
...
}
If we emitted a nested block for the break, the local loop would become
non-local. So we replace one kind of state with another.
Easiest course of action is to just emit the exact same cleanup code for
all conditional branches.
|
| |
|
|
|
|
|
| |
Turns out we can't handle them like conditional loops.
This function to emit cleanup code for jumps is getting quite terrible.
I don't yet know what subsidiary abstractions it needs.
|
| | |
|
| |
|
|
|
| |
Now that we have the infrastructure for emitting cleanup blocks, the labeled
variants should be easy as well.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Start pushing dummy vars for labels on the stack as we encounter them.
This won't affect cleanup code, but will make it easy to ensure that jumps
are well-structured.
|
| |
|
|
|
|
|
| |
Clean up data structures and eliminate the notion of named blocks.
Named blocks still exist in the Mu language. But they get parsed into a
uniform block data structure, same as unamed blocks.
|
| | |
|
| | |
|
| |
|
|
|
| |
Standardize on a single block name. This simplifies some code and will
also help in the next couple of steps.
|
| |
|
|
|
|
|
|
| |
This will come in handy for the remaining cases where we need to clean
up locals on the stack:
loop after var
non-local break with vars in intervening blocks
non-local loop with vars in intervening blocks
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
we detected labels using a '$' at the start of an arg, and turned them
into literals.
After:
we put labels on the var stack and let the regular lookup of the var
stack handle labels.
This adds complexity in one place and removes it from another. The crucial
benefit is that it allows us to store a block depth for each label. That
will come in handy later.
All this works only because of a salubrious coincidence: Mu labels are
always at the start of a block, and jumps always refer to the name at the
start of a block, even when the jump is in the forwards direction. So we
never see label uses before definitions.
Note on CI: this currently only works natively, not emulated.
|
| |
|
|
|
| |
Momentarily less efficient, but we will soon need the ability to emit cleanup
code without losing all our state.
|
| | |
|
| |
|
|
|
|
|
| |
Continuing to think about how to translate vars in a block when they're
followed by early exits. To clean up everything between a statement and
a target label, we need to know somehow the depth the target is defined
at.
|
| | |
|
| | |
|