| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Snapshot with new skeleton for parsing function body.
New test still failing, but only in the one expected place.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Function headers seem to be parsing right.
|
|
|
|
| |
Rudimentary support for parsing variable declarations.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Some groundwork for parsing.
|
|
|
|
|
|
|
|
|
| |
A couple more primitives now working. In the process I ran into an issue
with some buffer filling up when running ntranslate. Isolating it to survey.subx
was straightforward, but --trace ran out of RAM, and --trace --dump ran
out of (7GB of) disk. In the end what helped was just repeatedly inserting
exits at different points, and I realized there was a magic number that
hadn't been turned into a named constant.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
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
|
| |
|