| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Done with kinda-safe pointers.
In a real compiler the fast path of 'lookup' would ideally get inlined.
Excluding procedure-call overhead, the current implementation consumes 2
registers besides the input, and requires 9 instructions (2 push, 2 load,
compare, jump, increment, 2 pop). That's large enough that inlining may
become a trade-off. Even if we somehow magically had the registers already
loaded and available, we'd still need 4 instructions (1 pointer dereference,
compare, jump and increment). The price of safety.
|
|
|
|
| |
We only can't use rm32=5 when mod=0. Totally fine when it's mod=1.
|
| |
|
|
|
|
|
|
|
| |
Start with an exactly corresponding version to Crenshaw 2-1: single-digit
numbers. The only change: we assume the number is in hex.
The next version now supports multi-digit hex numbers.
|
|
|
|
| |
Simplification.
|
|
|
|
|
| |
This time I've ported (and test-driven) 'GetChar' and 'GetNum'. The new
tests bring together our new testable interfaces for read() and exit().
|
| |
|
|
|
|
|
|
| |
Start injecting all dependencies in the Crenshaw compiler app.
In the process I realized the non-fake code path of 'stop' had a bug.
|
|
|
|
|
|
|
| |
I've started testing more regularly on 64-bit Linux, and I realize that
the binaries actually now compare identical even on 64-bit. Why did I ever
add that condition to CI? Seems to be working now on Travis. Let's start
comparing now and see if the problem happens again.
|
|
|
|
|
|
|
|
|
|
| |
Turns out the tests for 'trace' have been broken in native mode since the
original commit (4674). Dangers of running my tests on Darwin, where I
can't run them natively.
The test failures didn't get flagged on CI because I'd forgotten to update
the exit code of the factorial app in commit 4664. At least that's fixed
in this commit.
|
| |
|
| |
|
|
Generated 32-bit binaries are different on 64-bit.
So let's compare them only on a 32-bit platform.
And let's start also verifying their run-time behavior on Linux.
|