Implement some i186+ instructions, and fix a few others

jart / blink

tiniest x86-64-linux emulator

ISC License

6.96k stars 222 forks source link

Implement some i186+ instructions, and fix a few others #106

Closed tkchia closed 1 year ago

tkchia commented 1 year ago

Implement clts (clear task-switched flag) instruction
Partly implement enter (make stack frame) instruction, for nesting level = 0
Fix operand size handling for leave, pusha, and popa instructions
Disassemble (but not yet execute) sldt, str, lldt, ltr, verr, and verw instructions (https://github.com/tkchia/blink/commit/00d8ba089453943ef8e3e25b8c38fe84c43de2ae)

tkchia commented 1 year ago

I hope to add some test programs for the instructions that are implemented or fixed. Thank you!

ghaerr commented 1 year ago

Hello @tkchia,

This looks great, you're really diving deep into the VM and filling holes :) The test suite code looks fantastic also.

Out of curiosity, is the deleted memcpy(m->sp, b[3], 2); in Popaw just an optimization because leave never uses the saved SP from the stack frame (i.e. no stack switch occurs and the value is always ignored, even though SP was saved by enter)?

Thank you!

tkchia commented 1 year ago

Hello @ghaerr,

Out of curiosity, is the deleted memcpy(m->sp, b[3], 2); in Popaw just an optimization because leave never uses the saved SP from the stack frame (i.e. no stack switch occurs and the value is always ignored, even though SP was saved by enter)?

(You mean popaw and pushaw?) Not only that — ignoring the pushed value of sp is actually more in line with what an actual x86 CPU actually does (as documented in the Intel manuals). Loading sp from the stack might actually change the instruction's behaviour.

Thank you!

tkchia commented 1 year ago

Hmm. I hope I have nailed down the correct way to determine the address and operand sizes for pusha and popa. Apparently a 0x66 prefix will change the size of the things being pushed, while a 0x67 prefix will simply be ignored.

I guess I should also add some checks to check that pusha and popa work as intended in 32-bit protected mode.

Thank you!

ghaerr commented 1 year ago

Apparently a 0x66 prefix will change the size of the things being pushed, while a 0x67 prefix will simply be ignored.

Wow, interesting. Are you finding this out via the Intel manual or real hardware? Does the push size default to the state of the D-bit (16 vs 32) in the stack or code segment (protected mode only, not real or long mode) and then possibly overidden?

tkchia commented 1 year ago

Hello @ghaerr,

Are you finding this out via the Intel manual or real hardware?

Both actually. Occasionally the Intel documentation might be wrong or unclear, so I have to run some code under either Linux/x64 or MS-DOS to see what it actually does.

Thank you!