about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* flag tests for opcode 3dKartik Agaram2019-05-131-4/+47
|
* .Kartik Agaram2019-05-131-5/+5
|
* .Kartik Agaram2019-05-131-3/+2
|
* .Kartik Agaram2019-05-133-13/+13
|
* flag tests for opcode 2dKartik Agaram2019-05-131-1/+46
|
* flag tests for opcode 81Kartik Agaram2019-05-131-17/+135
|
* flag tests for opcode 05Kartik Agaram2019-05-132-2/+51
|
* .Kartik Agaram2019-05-131-7/+8
|
* flag tests for opcode 3bKartik Agaram2019-05-131-3/+61
|
* .Kartik Agaram2019-05-133-54/+52
| | | | | | Standardize layout of some code fragments, and fix several bugs in computing the overflow flag in the process. a64 = b32 + c32 doesn't benefit from `a` being 64-bit without casting `b`.
* flag tests for opcode 2bKartik Agaram2019-05-131-7/+69
|
* .Kartik Agaram2019-05-131-8/+8
|
* flag tests for opcode 03Kartik Agaram2019-05-131-7/+69
|
* .Kartik Agaram2019-05-132-24/+46
| | | | | Make the first instruction described something that doesn't touch flags, so we don't introduce too much complexity all at once.
* carry flag thoroughly tested in layer 13Kartik Agaram2019-05-132-31/+131
| | | | | This is time-consuming mostly for me to come up with example scenarios testing all the different combinations of flags.
* .Kartik Agaram2019-05-132-20/+20
| | | | Correct some confusing log messages.
* CF needs special handling for some arithmetic opsKartik Agaram2019-05-125-86/+248
| | | | Inline some macro definitions.
* .Kartik Agaram2019-05-122-7/+0
| | | | Drop some prints as a first step to straightening things out.
* snapshot of carry flag implementationKartik Agaram2019-05-125-62/+147
| | | | | | | | | | | | | | | | | | 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
* 5157Kartik Agaram2019-05-112-10/+10
| | | | | Support allocating more than 0x01000000 bytes (8MB) to a segment in the VM.
* 5156 - error-checking on writes to fileKartik Agaram2019-05-119-0/+29
| | | | | | | 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?
* 5155 - check for overflow in mmap segmentsKartik Agaram2019-05-112-1/+12
|
* 5154Kartik Agaram2019-05-118-0/+2
| | | | | Bugfix: I'd neglected to update the input stream's state when natively writing a stream to file.
* 5153Kartik Agaram2019-05-119-95/+215
|
* 5152 - check for stack underflow/overflow in VMKartik Agaram2019-05-116-22/+33
|
* Merge pull request #28 from akkartik/allocate-using-mmapKartik Agaram2019-05-1019-96/+197
|\ | | | | Build `allocate` out of `mmap`
| * 5151 - use mmap everywhere we need a heapKartik Agaram2019-05-1015-45/+146
| | | | | | | | | | 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`.
| * 5150 - change interface for 'new-segment'Kartik Agaram2019-05-101-9/+25
| | | | | | | | Tests still failing. Passing until layer 53.
| * 5149Kartik Agaram2019-05-101-3/+8
| | | | | | | | Tests still broken.
| * 5148Kartik Agaram2019-05-095-47/+26
|/ | | | | Snapshot of incomplete work to have the memory allocator use `mmap` rather than `brk`. C tests pass, but the SubX layers are still broken.
* 5147Kartik Agaram2019-05-081-3/+3
|
* 5146Kartik Agaram2019-05-081-1/+1
|
* 5145Kartik Agaram2019-05-047-0/+0
|
* 5144Kartik Agaram2019-05-041-1/+7
| | | | | Pull in some final stylistic and debugging-friendly tweaks from my old version of commit 5132 and earlier.
* 5143 - add a bounds checkKartik Agaram2019-05-041-0/+10
| | | | | 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.
* 5142Kartik Agaram2019-05-041-12/+20
| | | | | | | | | 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.
* 5141Kartik Agaram2019-05-041-7/+7
| | | | Another minor stylistic point: I try to use EDI for destination operands.
* 5140 - fix an out-of-bounds bugKartik Agaram2019-05-041-2/+2
| | | | | | | | | | | 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.
* 5139Kartik Agaram2019-05-041-10/+6
| | | | | | | 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.
* 5138Kartik Agaram2019-05-041-11/+4
| | | | | | 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.
* 5137Kartik Agaram2019-05-041-77/+52
| | | | | | | | | | 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
* 5136 - test for a previous bugKartik Agaram2019-05-041-0/+30
| | | | Thanks Charles Saternos for the bugfix in 4a0b4344a3!
* 5135Kartik Agaram2019-05-047-0/+0
|
* Merge pull request #20 from akkartik/charles-l-print-int-decimalKartik Agaram2019-05-041-85/+97
|\ | | | | exercise: reimplement print-int-decimal
| * implemented solutionnc2019-05-031-1/+109
| |
| * Merge branch 'master' into charles-l-print-int-decimalnc2019-05-0111-59/+181
| |\ | |/ |/|
* | 5133 - show instruction source in traceKartik Agaram2019-04-287-14/+104
| | | | | | | | | | | | | | | | | | | | 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!
* | 5132Kartik Agaram2019-04-282-16/+1
| | | | | | | | Stop hackily tracing function being called. Trying something better.
* | 5131Kartik Agaram2019-04-277-32/+37
| | | | | | | | Rename '--map' to '--debug'.
* | 5130 - only show build status of 'master' branchKartik Agaram2019-04-271-1/+1
| |
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-27 10:53:58 +0000