VM86 project, source checking

[SANiK]

I'm starting to redo the X86 emu, but I do need my "base functions" checked for bugs. Don't you just huff and puff at the source, this has a real use in longmode.

Util functions, this file is used by the other functions:
(THIS FILE DOES NOT NEED TO BE DEBUGGED, IT'S THERE JUST SO YOU UNDERSTAND HOW THE CODE IS SETUP SO FAR!)
http://jamesseph.phpwebhosting.com/user ... il_ops.txt

My base functions: (They need to be checked. These functions do a mathematical operation and update the flags. I did them in a rush so I bet there's got to be a lot of bugs in em)
http://jamesseph.phpwebhosting.com/user ... ag_ops.txt

[Slasher]

Hi,
Just had a short look. You need to comment the code for us to understand what you want achieved.

Without it, we'd be guessing.

[Pype.Clicker]

i'm somehow surprised ... it looks like you're just emulating the instructions. So that's no longer the "transcoder" you told us about last time ?

[SANiK]

Well, the new plan WAS the translater/transcoder.
Thing is, that wouldn't work in longmode and would need a 32bit to 64bit layer.

So, I'm doing what Microsoft does and trying to make an "ntvdm.exe" which will run in long mode.

Code Slasher, well, here's a quick run down:
vm_addx(destination, increment, carryflag_affected)
1) destination+=increment
2) It sets the flags
3) If carryflag_affected is true, than calculate the CF. (For add operations)
If carryflag_affected is false, than don't calculate the CF. (For inc operations)

vm_subx(destination, decrement, carryflag_affected)
1) destination-=decrement
2) It sets the flags
3) If carryflag_affected is true, than calculate the CF. (For sub operations)
If carryflag_affected is false, than don't calculate the CF. (For dec operations)

vm_cmpx(value1, value2)
1) cmp value1, value2
2) It sets the flags

vm_rolx(value, rotate_amount)
1) Does a rotate LEFT operation, which is like a "warping" shift
2) It sets the flags

vm_rorx(value, rotate_amount)
1) Does a rotate RIGHT operation, which is like a "warping" shift
2) It sets the flags

vm_rclx(value, rotate_amount)
1) Does a rotate LEFT operation WITH CARRY, which is like a "warping" shift
2) It sets the flags

vm_rcrx(value, rotate_amount)
1) Does a rotate RIGHT operation WITH CARRY, which is like a "warping" shift
2) It sets the flags

vm_shlx(value, shift_amount)
1) Does a shift LEFT operation
2) It sets the flags

vm_shrx(value, shift_amount)
1) Does a shift RIGHT operation
2) It sets the flags

vm_sarx(value, shift_amount)
1) Does a shift arithmetic right
2) It sets the flags

vm_sbbx(destination, decrement)
1) Subtract with borrow
2) It sets the flags

vm_adcx(destination, decrement)
1) Add with carry
2) It sets the flags

As for the imul functions, one's a 3 operand one and the other is a one operand function. So don't let that confuse you.

The rest like XOR, AND, OR, TEST, MUL should be self explanatory.

[mystran]

I don't think there's anything wrong with pure emulation of realmode code for the purposes of running BIOS services.

The thing is, any performance critical realmode code dates from time when 386 was hot. Even if you wanted to run old games, pure emulation is still likely to be quick enough with modern processors.

[Pype.Clicker]

yes, sure. i wasn't concerned by performances, but rather by the size of the emulator code. Maybe it's just a useless concern, however. I was just figuring it would be smaller to have a program that sees 'okay, that's a MOD/RM operation, let's just rewrite those effective address encoding bits and see what it gets'. than rewriting everything else.

Now i admit that forward jumps, etc. might be a nightmare.

Just to make sure, isn't there a 32-bits emulation mode while in longmode that could be used to run translated BIOS code ? or is 16bits prefix override forbidden even in that 32-in-64 mode ?

[SANiK]

Well, another choice for going back to the interpretter is that I have like 90% of it done. I'm rechecking the opcodes. I have 50 of them checked. I just need you guys to check that file up there and if it sets the flags right.

The emulator binary comes out to 32.5 Kb.
With RLE, that becomes 29 Kb.
With dictionary/pattern compression it comes down to 10 Kb.
(Remember, adding decompression code to the kernel doesn't take up much space compared to a compression module)

[mystran]

I'd say that if size was truly an issue, it could probably be made even smaller, by doing fancy tricks implementing something like "microcode" and writing the opcode with that. Not that I see much point. Anything below ~64k is pretty small after all.

[AR]

Longmode's compatibility mode should operate identically (from the program's perspective) to 32bit protected mode, I think the prefixes also work in pure Longmode but I don't remember as it's been a while since I last looked at the docs (and are yet to put them to practical use).

There is a problem if you want the translator in the Longmode kernel as the kernel segment must be 64bit flat (IIRC) so the translator needs to translate to 64bit compatible code, if the o16 prefix does actually work in 64bit mode then this wouldn't be a problem.

[SANiK]

Well, proxy checked the code and he says it looks fine.

Hopefully someone else can check it just to be sure, cause it has a LOT of math. Which means that there is a lot of potential for incorrect calculations.