| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Correct some confusing log messages.
|
| |
|
|
| |
Inline some macro definitions.
|
| |
|
|
| |
Drop some prints as a first step to straightening things out.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tests failing.
This approach seems wrong. I'm not sure even the tests are correct. Also,
some open questions:
1. Should setting the overflow flag always set the carry flag?
2. Should the carry flag only be set on add/subtract/compare, or by all
arithmetic ops?
3. Had to turn off the -ftrapv flag in `build`. Is there a way to detect
overflow without actually causing overflow?
Once we start setting CF correctly we have to implement jump above/below
instructions (8- and 32-bit displacement variants).
https://github.com/akkartik/mu/issues/30
|
| |
|
|
|
| |
Support allocating more than 0x01000000 bytes (8MB) to a segment in the
VM.
|
| |
|
|
|
|
|
| |
Pretty blunt for now; just abort the entire program on any failure to write.
I'm encountering it because I'm somehow treating a stream address as a
file descriptor. Maybe mmap is returning addresses below 0x08000000?
|
| | |
|
| |
|
|
|
| |
Bugfix: I'd neglected to update the input stream's state when natively
writing a stream to file.
|
| | |
|
| | |
|
| |\
| |
| | |
Build `allocate` out of `mmap`
|
| | |
| |
| |
| |
| | |
All tests passing now. Things are very explicit; before a program can `allocate`
memory, it has to first obtain a segment from the OS using `new-segment`.
|
| | |
| |
| |
| | |
Tests still failing. Passing until layer 53.
|
| | |
| |
| |
| | |
Tests still broken.
|
| |/
|
|
|
| |
Snapshot of incomplete work to have the memory allocator use `mmap` rather
than `brk`. C tests pass, but the SubX layers are still broken.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Pull in some final stylistic and debugging-friendly tweaks from my old
version of commit 5132 and earlier.
|
| |
|
|
|
| |
We'll just loudly abort the entire program if the output stream isn't large
enough to accept all the characters we want to print.
|
| |
|
|
|
|
|
|
|
| |
Hoist address computation out of the loop.
I'm giving in to the temptation to optimize here, and violating my own
rule of minimizing local variables by introducing 'curr'. My fig leaf is
that the number of instructions inside the loop goes down, and duplicating
inside the loop may be distracting to readers.
|
| |
|
|
| |
Another minor stylistic point: I try to use EDI for destination operands.
|
| |
|
|
|
|
|
|
|
|
|
| |
We were writing 32-bit words when we meant to write 8-bit bytes. Most of
the time this doesn't matter because:
* x86 is little endian,
* a write to (x, x+1, x+2, x+3) is over-written by
the next to (x+1, x+2, x+3, x+4), and
* the 3 higher/later bytes are always 0 so no information is lost
The only place this matters is if we're close to the end of the stream.
|
| |
|
|
|
|
|
| |
Replace the 'negative?' variable with a second read from the stack.
It's not clear if this is more or less efficient (https://github.com/akkartik/mu/pull/20#issuecomment-489285130)
but taking out the local variable does seem easier to read.
|
| |
|
|
|
|
| |
Drop some redundant transfers between registers. The x86 instruction set
can perform most operations on all available registers, and things are
more comprehensible if each conceptual variable has a single location.
|
| |
|
|
|
|
|
|
|
|
| |
A few minor stylistic things that may ease reading, but not significantly
enough that I care to force others to follow them:
* no end-of-line comments for instructions without /rm32
* arguments either at tab stops or after 2 spaces
* compare 'with' when using in asymmetric tests (greater/lesser),
compare 'and' for symmetric equality checking
* prefix internal labels with function name
|
| |
|
|
| |
Thanks Charles Saternos for the bugfix in 4a0b4344a3!
|
| | |
|
| |\
| |
| | |
exercise: reimplement print-int-decimal
|
| | | |
|
| | |\
| |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It's a little hacky in some corner cases. In particular, if debug information
isn't available the trace will contain duplicated lines. This is because
I don't want the core trace lines all my tests rely on (introduced in the
'vm' layer) to have to know about debug info (introduced in the 'labels'
and 'debug' layers).
Thanks Charles Saternos for the feedback and suggestion!
|
| | |
| |
| |
| | |
Stop hackily tracing function being called. Trying something better.
|
| | |
| |
| |
| | |
Rename '--map' to '--debug'.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|