OSDev.org

OK, I know many of us are currently developing long mode operating systems. Which, annoyingly, can't access v8086 mode.

Now, one thing of note is that real mode and 16-bit protected mode are very similar. My thought was this:
* Set up 6 16-bit segments (For each of the registers) in the GDT or LDT
* Point the data ones at, well, the data the functions expect
* The code one contains the 16-bit code, verbatim, except segment loads, jumps and perhaps software interrupts are replaced with far calls/jumps to the emulator

How feasible do people think this would be? It wouldn't be the fastest method in the world (16-bit protected mode is quite slow on modern processors), but it certainly should be faster than emulation, and should certainly be faster than translation to 32-bit protected mode.

Dynamic recompilation. Yes it would work, and it would probably do so with decent speed.

I do think that converting to 32 mode would be faster than oldschool emulation - you only need to convert the code once, and it runs full speed afterwards. With a bit of luck it will even be faster than your first method. Think about it, is each change of segment register going to cause a system call, in which case much of the speed improvement will be lost?

Hi,

Combuster wrote:I do think that converting to 32 mode would be faster than oldschool emulation - you only need to convert the code once, and it runs full speed afterwards. With a bit of luck it will even be faster than your first method. Think about it, is each change of segment register going to cause a system call, in which case much of the speed improvement will be lost?

The problem with Owen's idea is that each change of a segment register might not cause an exception. For example "push cs; pop ds" should work in real mode, but won't work in 16-bit protected mode (because CS is "read/execute" and can't be "read/write/execute") - you won't get an exception for "pop ds" and when you do get an exception (e.g. from attempting to write to DS) it's too late to figure out what DS is meant to be. There's similar problems with other instructions (where you don't get an exception where you need it); including things like SGDT, SLDT, SIDT and POPF.

Because of these problems, to do it properly you need to scan the instructions before they're executed and replace anything that shouldn't be executed (e.g. "push cs") with either corrected code or code that will cause a trap/exception. This is actually how at least one of the emulators works (maybe older versions of VMware?).

Of course then there's the more general problem - the BIOS is real mode code, and it's crappy code (slow, single-tasking code that expects full access to all hardware and assumes all the hardware is in it's "legacy" state); and regardless of what you do to get past the first problem it won't help with the second problem (unless you emulate all the hardware too, or write a "BIOS extender" OS that never uses any modern features like APICs, HPET, USB, etc).


Cheers,

Brendan

Brendan wrote:The problem with Owen's idea is that

The problem with Owen's idea is that iirc, in long mode not only v8086 is not supported, but neither is 16-bit protected mode.


JAL

AMD's documentation explicitly states 16-bit compatibility mode exists and works.

Heck, their sample long mode enabling code requires it (It is in 16-bit mode when it turns on long mode.

I was only planning on using the system for my VESA video driver - and maybe to implement a DOS emulator or such (Which would use a custom dummy BIOS, of course). Or would even the VBE barf when it discovered I was using the APIC?

I was intending to scan the code ahead of time for segment overrides and far jumps, and probably replace them with INT3s. The time taken doing the emulated->kernel->emulator transitions (And the then following system calls to update the LDT) would be high, but probably insignificant in the grand scheme of things.

Owen wrote:AMD's documentation explicitly states 16-bit compatibility mode exists and works.

You are right. I checked the Intel manuals and it is indeed possible. I think I got confused because Win64 does not allow Win16 apps to run. This must be for a different reasons.

I was intending to scan the code ahead of time for segment overrides and far jumps

That would need a thorough, almost impossible, analyzing of code. If you can do that, you can translate the code as well, not needing any further trickery.

The time taken doing the emulated->kernel->emulator transitions (And the then following system calls to update the LDT) would be high, but probably insignificant in the grand scheme of things.

Probably, but like other's commented above, it's a dead end. It just doesn't work. I'd take a look at the virtualization extensions of modern processors, which allow running a virtual real mode (even better than v86?), or use an emulator instead.


JAL