| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Using these is quite unsafe. But what isn't, here?
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I built this in 3 phases:
a) create a helper in the bootstrap VM to render the state of the stack.
b) interactively arrive at the right function (tools/stack_array.subx)
c) pull the final solution into the standard library (093stack_allocate.subx)
As the final layer says, this may not be the fastest approach for most
(or indeed any) Mu programs. Perhaps it's better on balance for the compiler
to just emit n/4 `push` instructions.
(I'm sure this solution can be optimized further.)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It makes no sense to know where the next variable will start before I've
seen it or how much space it needs. Things have only been working so far
because all variables take 4 bytes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We can't do it during parsing time because we may not have all type definitions
available yet. Mu supports using types before defining them.
At first I thought I should do it in populate-mu-type-sizes (appropriately
renamed). But there's enough complexity to tracking when stuff lands on
the stack that it's easiest to do while emitting code.
I don't think we need this information earlier in the compiler. If I'm
right, it seems simpler to colocate the computation of state close to where
it's used.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Move computation of offsets to record fields into the new phase as well.
Now we should be robust to type definitions in any order.
|
| |
|
|
|
|
|
|
|
|
| |
Move out total-size computation from parsing to a separate phase.
I don't have any new tests yet, but it's encouraging that existing tests
continue to pass.
This may be the first time I've ever written this much machine code (with
mutual recursion!) and gotten it to work the first time.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Finally we're now able to track the index of a field in a record/struct/product
type.
|
| |
|
|
| |
Free up eax using the newly available register.
|
| |
|
|
| |
Create space for another local.
|
| |
|
|
|
| |
parse-mu-types has a lot of local state. Move a local to the stack to free
up a register.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Make room for additional information for each field in a record/product
type.
Fields can be used before they're declared, and we may not know the offsets
they correspond to at that point. This is going to necessitate a lot of
restructuring.
|
| |
|
|
| |
Fix a bug with a live register being clobbered.
|
| | |
|
| |
|
|
|
| |
It was premature to say user-defined record types and array types were
done.
|
| |
|
|
|
|
| |
I thought I needed to support compute-offset with literal index, but in
that case might as well just use an index literal directly. The 'index'
instruction with literals already supports non-power-of-2 sizes.
|
| |
|
|
| |
A new test, and a new bugfix.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If indexing into a type with power-of-2-sized elements we can access them
in one instruction:
x/reg1: (addr int) <- index A/reg2: (addr array int), idx/reg3: int
This translates to a single instruction because x86 instructions support
an addressing mode with left-shifts.
For non-powers-of-2, however, we need a multiply. To keep things type-safe,
it is performed like this:
x/reg1: (offset T) <- compute-offset A: (addr array T), idx: int
y/reg2: (addr T) <- index A, x
An offset is just an int that is guaranteed to be a multiple of size-of(T).
Offsets can only be used in index instructions, and the types will eventually
be required to line up.
In the process, I have to expand Input-size because mu.subx is growing
big.
|
| |
|
|
| |
Some much-needed reorganization.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a 3-operand instruction:
r32 = rm32 * imm32
It looks like https://c9x.me/x86/html/file_module_x86_id_138.html has a
bug, implying the same opcode supports a 2-operand version. I don't see
that in the Intel manual pdf, or at alternative sites like https://www.felixcloutier.com/x86/imul
Native runs seem to validate my understanding.
In the process I also fixed a bug in the existing multiply instruction
0f af: the only flags it sets are OF and CF. The other existing multiply
instruction f7 was doing things right.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Support parsing ints from strings rather than slices.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the process I'm starting to realize that my approach to avoiding spills
isn't ideal. It works for local variables but not to avoid spilling outputs.
To correctly decide whether to spill to an output register or not, we really
need to analyze when a variable is live. If we don't do that, we'll end
up in one of two bad situations:
a) Don't spill the outermost use of an output register (or just the outermost
scope in a function). This is weird because it's hard to explain to the
programmer why they can overwrite a local with an output above a '{' but
not below.
b) Disallow overwriting entirely. This is easier to communicate but quite
inconvenient. It's nice to be able to use eax for some temporary purpose
before overwriting it with the final result of a function.
If we instead track liveness, things are convenient and also easier to
explain. If a temporary is used after the output has been written that's
an obvious problem: "you clobbered the output". (It seems more reasonable
to disallow multiple live ranges for the output. Once an output is written
it can only be shadowed in a nested block.)
That's the bad news. Now for some good news:
One lovely property Mu the language has at the moment is that live ranges
are guaranteed to be linear segments of code. We don't need to analyze
loop-carried dependences. This means that we can decide whether a variable
is live purely by scanning later statements for its use. (Defining 'register
use' is slightly non-trivial; primitives must somehow specify when they
read their output register.)
So we don't actually need to worry about a loop reading a register with
one type and writing to another type at the end of an iteration. The only
way that can happen is if the write at the end was to a local variable,
and we're guaranteeing that local variables will be reclaimed at the end
of the iteration.
So, the sequence of tasks:
a) compute register liveness
b1) verify that all register variables used at any point in a program
are always the topmost use of that register.
b2) decide whether to spill/shadow, clobber or flag an error.
There's still the open question of where to attach liveness state. It can't
be on a var, because liveness varies by use of the var. It can't be on a
statement because we may want to know the liveness of variables not referenced
in a given statement. Conceptually we want a matrix of locals x stmts (flattened).
But I think it's simpler than that. We just want to know liveness at the
time of variable declarations. A new register variable can be in one of
three states w.r.t. its previous definition: either it's shadowing it,
or it can clobber it, or there's a conflict and we need to raise an error.
I think we can compute this information for each variable definition by
an analysis similar to existing ones, maintaining a stack of variable definitions.
The major difference is that we don't pop variables when a block ends.
Details to be worked out. But when we do I hope to get these pending tests
passing.
|
| | |
|
| | |
|
| |
|
|
|
| |
The second var to the same register in a block doesn't need to spill. We're
never going to restore the var it's shadowing.
|