OSDev.org

Plus you can't preempt real mode, an emulator can be.

...but you can preempt VMode... so that really doesnt count as a reason to use this...

there may be good reasons for this, but preemption isnt one of them

AFIK you cannot use VM8086 mode when in long mode so and emulator could be used to run real mode apps and execute bios calls.

thepowersgang wrote:AFIK you cannot use VM8086 mode when in long mode so and emulator could be used to run real mode apps and execute bios calls.

True, but almost all long mode-capable CPUs also have virutalization extensions that can be used for this.


JAL

thepowersgang wrote:AFIK you cannot use VM8086 mode when in long mode so and emulator could be used to run real mode apps and execute bios calls.

didnt mean to imply that you could... but you cant do RMode in LMode either...

i was specifically replying to the previous post, where it was said that one advantage of this was that you cant preempt RMode...


however, i do expect my OS to (eventually) be able to run 64bit programs simultaneously with RMode programs (using VMode to run the RMode programs...) because it will be capable of switching between LMode and PMode on task-switch... (although this is a lower priority goal)

JAAman wrote:however, i do expect my OS to (eventually) be able to run 64bit programs simultaneously with RMode programs (using VMode to run the RMode programs...) because it will be capable of switching between LMode and PMode on task-switch... (although this is a lower priority goal)

You are saying two things: 1) you are running rmode in vmode together with long mode, but this is just not possible, since long mode has no vmode and 2) you are running rmode in rmode, and lmode in pmode. As for the latter, you do realize that a) this is dead-slow, b) you can only run one real-mode application (if you drop to realmode, your paging is gone, so only identity mapping), c) this is very dangerous (the program running from real mode can switch to pmode, and trash your OS)? If not, you are hereby warned and, if so, you are very stupid (no insult intended).


JAL

If you read it carefully, it says something different. JAAman's scheduler does exactly what I had in mind for mine.

The trick is, the scheduler described can switch between long mode and protected mode, which means that the kernel is not restricted to the limitations of either. to schedule a real mode task, it will drop to PMode (if it was in long mode), then from there enter v8086 mode to do whatever is needed. Then for the next task it will be interrupted to protected mode, which again re-enters long mode, to continue with the 64 bit program that was also running.

Combuster wrote:The trick is, the scheduler described can switch between long mode and protected mode, which means that the kernel is not restricted to the limitations of either. to schedule a real mode task, it will drop to PMode (if it was in long mode), then from there enter v8086 mode to do whatever is needed. Then for the next task it will be interrupted to protected mode, which again re-enters long mode, to continue with the 64 bit program that was also running.

Which is still dead slow, probably. And needs some careful memory layouting to avoid > 32 bit addresses containing necessary information when in pmode. I'd just go for vmode, even if it is not available on all machines, or emulation.


JAL

Which is the purpose of this emulator. I intend to make it more customizable soon, like enabling/disabling port access and using a custom IVT location (even cloning the 1st 1Mb of memory and running it off that.

@jal

Which is still dead slow, probably.

Which you didn't measure and as such, is a uneducated guess:
- Not having the emulation layer is way faster than having to interpret each and every instruction.
- The task switch only requires a reload of an additional 2 special registers (EFER, IDTR), CR3 is reloaded as part of the address space switch (which you will have anyway), cr0 is reloaded (sets the TS bit) to support lazy FPU switches.

And needs some careful memory layouting to avoid > 32 bit addresses containing necessary information when in pmode.

And PAE paging can solve a lot of your address space issues. In fact, you can reuse long mode's page tables if you're careful enough.

I'd just go for vmode,

Which is exactly what we do.

Come on, You can do better than that.

You are saying two things:

not really...

1) you are running rmode in vmode together with long mode, but this is just not possible, since long mode has no vmode and

yes it is possible -- you cant run VMode in LMode, but you can run it with LMode... as combuster said... he was exactly right... didnt expect anyone else to try anything this crazy though...

2) you are running rmode in rmode, and lmode in pmode.

of course not... RMode has no place in any PMode-capable OS...

Which is still dead slow, probably.

yes, its not exactly meant to be fast (after all, if you want your program to run fast, you must use JaaOS native PMode or LMode interface, and not be running in old DOS emulators in simulated RMode...) -- and of course its still much faster than the per-instruction software emulation

-- and of course this will only be necessary if there are both RMode and 64bit applications running simultaneously on a 64bit CPU... (which will always give lower time to the RMode process anyway)

And needs some careful memory layouting to avoid > 32 bit addresses containing necessary information when in pmode.

no, as combuster said, PMode has had full access to 64GB of physical memory since the P6 (begining with the PentiumPro ~1995?) and has since been extended to support the full address space in PMode...

my os uses PAE on all CPUs for which it is available



your idea may not be bad, and does have merits, but im just mentioning an alternate possibility

Combuster wrote:Which you didn't measure and as such, is a uneducated guess:
- Not having the emulation layer is way faster than having to interpret each and every instruction.

My concern is not the speed of the real mode application, since these are written decades ago anyway, and therefore uauslly fast enough in emulation, but the speed impact on the whole OS, when running multiple realmode tasks and many switches between them and the other tasks in the OS. But you are right, it's just an (un)educated guess, so I may be dead wrong (wouldn't be the first time).


JAL

I'm not quite sure how far into your project and cpu emulation you are, but if you have trouble with certain opcodes, you may be interested in looking at my little project I started a while ago, it's in the form of a library, and in C++(a bad thing for OS deving, but anyway) it has full 8086 support, and partitial 186 opcodes.. it's at http://x86lib.sf.net if you want to check it out or something...

[edit]
or maybe I'll look at your source when I have problems.. lol

[edit2]
btw, if you'd like a more permanent host (or a backup host in case your self hosting is down) contact me at "hosting -AT- earlz.biz.tm" I'm giving away hosting to who ever wants it...

I'll check up on that project, and thanks for the hosting offer but self hosting is fine for me atm. If this graduates to a more serious project I'll make a project on SourceForge and GPL it.