| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
More calling convention tweaks.
Use EBP to get consistently at parameters and locals.
Always put the first function argument closest to EBP.
|
| |
|
|
| |
Get the calling convention right, per http://www.cs.virginia.edu/~evans/cs216/guides/x86.html
|
| | |
|
| | |
|
| |
|
|
| |
Upgrade the test harness for the factorial "app" from ex11.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
check_ints_equal now prints a newline after the failure message on failure.
We still don't know how to print a final newline after all the tests have
run, for the common case when all tests pass.
Ideally I could just emit a few instructions to `run_tests`. But I'd also
need to add a variable for the newline to the data segment. Or I need some
literal syntax for newlines in strings. We don't have support for backslash-escapes
yet.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Extract a helper from the factorial unit test: check_ints_equal.
Start of a vocabulary for unit tests.
I *could* also start thinking of supporting multi-file programs, but I'm
going to resist the temptation for now. Copy helpers as necessary, and
allow them to mutate and diverge for a while before we pummel them into
a Procrustean "standard library". Extracting a body of shared code immediately
starts to discourage innovation in the shared code.
|
| |
|
|
|
| |
No automated tests for argv_equal because we need it to run automated tests.
But maybe we should have them anyway.
|
| |
|
|
|
|
|
|
|
| |
All it takes is to code-generate a simple function called 'run_tests' that
calls all functions starting with 'test_' one by one.
I've temporarily switched the factorial app to run as a test. But that's
temporary, because all the code to print '.' vs 'F' needs to get extracted
out into a helper.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Streamline the factorial function; we don't need to save a stack variable
into a register before operating on it. All instructions can take a stack
variable directly.
In the process we found two bugs:
a) Opcode f7 was not implemented correctly. It was internally consistent
but I'd never validated it against a natively running program. Turns out
it encodes multiple instructions, not just 'not'.
b) The way we look up imm32 operands was sometimes reading them before
disp8/disp32 operands.
|
| |
|