| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
Try to make the comments consistent with the type system we'll eventually
have.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Rather surprisingly, all the treeshake tooling is done in just about 2
hours of work. From now on it'll be easier to update stats.txt. Observations:
a) Binaries are tiny compared to conventional stacks. Tens of KB.
b) ~80% of binaries are tests and unused libraries in all my apps.
c) ~75% of LoC in SubX sources are tests or comments.
|
|
|
|
|
| |
Fix a bug in one test: it checks eax when the component under test returns
nothing. It's been just accidentally passing all these months.
|
|
|
|
|
|
| |
Standardize conventions for labels within objects in the data segment.
We're going to use this in a new tool.
|
|
|
|
|
| |
All tests passing again. We have big gaping holes for type- and var-management.
We're going to work on the latter first.
|
|
|
|
|
| |
Lots of debugging to add two curly braces. I need tests for populate-mu-function-body,
or even parse-mu-block.
|
| |
|
|
|
|
|
| |
parse-mu-stmt now working, though we'll need to go back and stop creating
a new var for every instance of a variable in a scope.
|
| |
|
|
|
|
|
| |
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.
|
| |
|