| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Support function calls with literal arguments.
|
|
|
|
| |
Support binary instructions with an immediate operand.
|
|
|
|
|
|
|
|
|
| |
Binaries are now identical again.
There's a little hack here that we should clean up at some point. But it
requires more thought.
Ordering compiler phases is hard. So far we're only at the start of the
slippery slope into that abyss.
|
|
|
|
|
|
|
| |
Support binary operations with reg/mem and reg operands.
Everything is passing. However, the self-hosting translator now generates
some discrepancies compared to the C++ translator :(
|
|
|
|
|
| |
So far this is just the same as our most recent tests. But now we have a
'DSL' for adding more primitives.
|
|
|
|
|
| |
We can now compile primitive statements while selecting the right template
to code-gen each one from. Even when multiple templates have the same name.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After much struggle, one more test: emitting a primitive with a register
operand.
The following two instructions have the same name:
reg <- increment
increment var
and they emit the same opcodes:
ff 0/subop
But they're considered distinct policies in the code-generation 'table',
one for incrementing variables on the stack and the other for incrementing
variables in a register.
|
|
|
|
|
|
| |
I've been under-estimating the complexity of translating primitive statements.
We need to separately track information for each primitive about operands
for both the source and emitted SubX notation.
|
| |
|
| |
|
|
|
|
| |
No, let's represent register as just a string to save a translation.
|
|
|
|
|
| |
Support variables at positive stack offsets (formal parameters for functions),
and also an indicator for 'any register' for primitive operations.
|
| |
|
|
|
|
| |
Add mu.subx to CI.
|
| |
|
|
|
|
|
|
|
|
| |
Rethink how vars are organized. We need separate aggregates for vars in
the definition stack, defined in function headers, and used by statement
operands. So now vars have no 'next' fields themselves. The definition
stack will be a real stack, while the function headers and statement operands
will have separate 'next' fields.
|
|
|
|
| |
Switching gears to emitting function calls. The function name is working now.
|
|
|
|
| |
No, we need to handle primitives and calls separately.
|
| |
|
| |
|
| |
|
|
|
|
| |
Just a random snapshot of mu.subx. The two new tests aren't passing yet.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Already http://akkartik.name/post/mu-2019-2 is out of date.
|
| |
|
|
|
|
| |
http://akkartik.name/post/mu-2019-2
|
| |
|
|
|
|
|
|
|
| |
Clean up pseudocode to match planned syntax for the type- and memory-safe
level-2 Mu language.
http://akkartik.name/post/mu-2019-2 is already out of date.
|
|
|
|
| |
Replace calculations of constants with labels.
|
| |
|
| |
|
|
|
|
|
| |
Thanks Mateusz Czapliński for the feedback:
https://lobste.rs/s/xtxlec/mu_minimal_hobbyist_computing_stack#c_1mzq94
|
| |
|
|
|
|
| |
Thanks Andrew Owen for reporting this typo.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Move stack operations to a layer of their own.
It was some short-term pain to take out the syntax sugar from it, but we
need access to this layer from braces, which can't depend on sugar since
it's part of sugar. Just simpler to keep one clear line and not have to
build sometimes with some sugar but not others.
|
|
|
|
| |
Get mulisp reflecting whatever's typed in again.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This undoes 5672 in favor of a new plan:
Layers 000 - 099 are for running without syntax sugar. We use them for
building syntax-sugar passes.
Layers 100 and up are for running with all syntax sugar.
The layers are arranged in approximate order so more phases rely on earlier
layers than later ones.
I plan to not use intermediate syntax sugar (just sigils without calls,
or sigils and calls without braces) anywhere except in the specific passes
implementing them.
|
| |
|
| |
|