Original thread: http://forum.osdev.org/viewtopic.php?f=1&t=10321
You are doing something wich can be called "JIT" Just-In-Time Translation.
Why not follow another logic : Translate before use. ?
On PC motherboards theres a thing called RAM Shadow, were the contents of the BIOS ROM is copied to RAM to speed-up the BIOS.
You can do something similar : Allocate a memory area, but instead of copying the BIOS from ROM to RAM, copy the translated opcodes...
I think this will solve stack problems and simplify the code...
The future method of doing VM86? - new discussion on JIT
-
jorgealdojr
- Posts: 4
- Joined: Fri Aug 20, 2010 7:02 am
Re: The future method of doing VM86? - new discussion on JIT
Comments on necromancing removed; there's this "tell moderator" button that works for that. Can we get back to topic now?
-
jorgealdojr
- Posts: 4
- Joined: Fri Aug 20, 2010 7:02 am
Re: The future method of doing VM86? - new discussion on JIT
One person said that it would be impossible due to access to other segments (etc).
Generally the translation would be hard only if the code used indirect jumps (Like call tables etc). Segment registers can be mimmicked. We are translating, we have all freedom to implement equivalent code.
I don't think this is much used in BIOS. I bet most of instructions are ordinary ones.
We are talking about hardware initialization and the like.
Even on more complex stuff translation works (Look at Rosetta project on macos).
Generally the translation would be hard only if the code used indirect jumps (Like call tables etc). Segment registers can be mimmicked. We are translating, we have all freedom to implement equivalent code.
I don't think this is much used in BIOS. I bet most of instructions are ordinary ones.
We are talking about hardware initialization and the like.
Even on more complex stuff translation works (Look at Rosetta project on macos).
Re: The future method of doing VM86? - new discussion on JIT
Some remarks.
V86 mode has been removed from 64-bit (long mode), but it still works in 386-mode. That means that for the moment 32-bit OSes can still use V86 mode on newer CPUs, while 64-bit OSes need to resort to emulation. Well, there is also extensive emulation support in newer CPUs, but I'm unsure if those could handle V86/real mode.
However, to prepare for the future, it might be best to not rely too much on V86 mode being retained in "compability mode".
I use a similar translation method in my "emulator" in RDOS. I basically first decode the operands (with segment registers as needed), and then execute the original instruction modified with new operands in protected mode. This should be faster than pure emulation, and also easier since there is no reason to emulate flag side-effects or the opcodes themselves.
V86 mode has been removed from 64-bit (long mode), but it still works in 386-mode. That means that for the moment 32-bit OSes can still use V86 mode on newer CPUs, while 64-bit OSes need to resort to emulation. Well, there is also extensive emulation support in newer CPUs, but I'm unsure if those could handle V86/real mode.
However, to prepare for the future, it might be best to not rely too much on V86 mode being retained in "compability mode".
I use a similar translation method in my "emulator" in RDOS. I basically first decode the operands (with segment registers as needed), and then execute the original instruction modified with new operands in protected mode. This should be faster than pure emulation, and also easier since there is no reason to emulate flag side-effects or the opcodes themselves.