OSDev.org

I was thinking since I am a beginner at this that my kernel would just stay in 16-bit mode with limited memory accessing, but I wanted to know if it's physically-hardware possible to do context switches with the PIT in Real Mode of x86.

That is, can you set the PIT, have different stacks, switch the context between them, have them all run segregated from each other, and multitask?

Is this something only hardware-supported in Protected Mode, or no? Thanks.

Context switching (or thread switching in this case) can be implemented in real mode as well.

What I don't know is how well BIOS calls can handle preemption.

So it is not restricted by any CPU flag, bit, or otherwise mode of operation(circuitry)?

I have another question about "Ring Security" in x86 I should bother adding here:

If you don't specify or change/alter which bit flag, or flag, that denotes which level of control a program runs in on either a particular stack or the like, what is the default privilege level for a kernel, bootloader, etc.?

Also, isn't it possible to be void of BIOS firmware calls after your kernel/code is in memory?

Like, can't you just use normal MMIO, and read/write to mapped video memory, RAM, etc., directly in Real Mode?

Since virtual memory is not supported in Real Mode because of the MMU or such, all programs, "user" or "kernel" privilege memory addressing, would have to directly access mapped memory, and none virtualized/isolated by virtual memory schemes, unless otherwise implemented through software entirely somehow.

Can you do it in real mode? Yes. Is it a good idea? About as good of an idea as eating nothing but Big Macs for a month. It may seem delicious at first, but by the end of the month it's probably going to kill you.

We've had threads about this recently. The answer is usually "don't bother trying, and if you do, you're on your own and godspeed".


EDIT: Lemme see if I can answer some questions.

LieutenantHacker wrote:If you don't specify or change/alter which bit flag, or flag, that denotes which level of control a program runs in on either a particular stack or the like, what is the default privilege level for a kernel, bootloader, etc.?

Kernel mode (ring 0), but in real mode, there are no privilege levels at all. Privilege levels are a protected mode concept.

LieutenantHacker wrote:Also, isn't it possible to be void of BIOS firmware calls after your kernel/code is in memory?

Mostly. System Management Mode might be invoked, which could call something in the BIOS firmware (if it exists; see UEFI).

LieutenantHacker wrote:Like, can't you just use normal MMIO, and read/write to mapped video memory, RAM, etc., directly in Real Mode?

Sure, but once you hit MMIO past 1 MB you either need protected mode or unreal mode, the latter of which is another delicious Big Hack for breakfast, lunch and dinner.

Sure, but once you hit MMIO past 1 MB you either need protected mode or unreal mode, the latter of which is another delicious Big Hack for breakfast, lunch and dinner.

But what is your point exactly? Are you advising I don't bother with 16-bit addressing/Real Mode altogether?

Regardless of being in 16, 32, or 64-bit mode you still have to access memory, and mapped memory as well, such as with MMIO, or port I/O, or some other way I'm uncertain of.

Are you more strictly warning of the segmented addressing and small memory limits of Real Mode advising I should just not bother will it altogether, or is there something else I'm missing here that you're hinting at?

EXTRA:

Privilege levels are a protected mode concept.

So Long Mode doesn't have privilege levels?

Hi,

I'm going to answer in the hope the OP isn't just trolling...

LieutenantHacker wrote:But what is your point exactly? Are you advising I don't bother with 16-bit addressing/Real Mode altogether?

Do you have a reason for staying in RM other than the fact that you are a beginner (as stated in your original post)? If not, then I would suggest giving RM "a miss" and getting to PMode / Long Mode and executing your main kernel from there.

LieutenantHacker wrote:Regardless of being in 16, 32, or 64-bit mode you still have to access memory, and mapped memory as well, such as with MMIO, or port I/O, or some other way I'm uncertain of.

Yes - but as Blacklight stated, you cannot use MMIO past 1MiB in pure Real Mode. Any way of accessing MMIO above that level, but keeping the CPU in a 16 bit mode will be hackish (I feel based on your previous "Long Mode" comment, I should add the rider about 0xFFFF:0xFFFF being above 1MiB).

LieutenantHacker wrote:Are you more strictly warning of the segmented addressing and small memory limits of Real Mode advising I should just not bother will it altogether, or is there something else I'm missing here that you're hinting at?

I don't think there's any hinting going on here. There are good reasons for the following and a little research on the forum and wiki will reveal the more in-depth reasons.

Blacklight wrote:We've had threads about this recently. The answer is usually "don't bother trying, and if you do, you're on your own and godspeed".

LieutenantHacker wrote:So Long Mode doesn't have privilege levels?

This is the section that makes me feel that this is just trolling. If it's a genuine question, then the wiki will help you with the answer.

Cheers,
Adam

I assure anyone here that I'm not trolling, even if it may seem so. I realize I could dig through the Wiki, but Wiki doesn't cover ever question I have, nor does it answer every concern in a manner everyone can completely understand well.

I just honestly wanted to know if Real Mode is capable of context switches and multiple stacks and processes, etc.

Please search the forum, there was a recent thread on the subject (that kinda got into a flamewar). I think the conclusion was "Yes, it is possible with some hacks, but real mode is a piece of crap and you should just move onto protected mode that was _designed_ for this".

LieutenantHacker wrote:I was thinking since I am a beginner at this that my kernel would just stay in 16-bit mode with limited memory accessing, but I wanted to know if it's physically-hardware possible to do context switches with the PIT in Real Mode of x86.

That is, can you set the PIT, have different stacks, switch the context between them, have them all run segregated from each other, and multitask?

You can have separate stacks and multitask, but you can't keep things segregated from each other, or prevent any given task from overwriting your PIT handler (and/or any other interrupt handler, and/or the memory used by any task, and/or the operating system itself, etc) and making itself the only task running on the system.

As for context switching, it depends greatly upon what you mean. If you just mean "restore the previously saved state of a task so it can continue", yes, you can, though you can't guarantee that tasks won't mess with each other's state information. If you mean "change addressing contexts to keep tasks separate from messing with each other", then no, you can't.

I never say never, so I will attempt things my own way.

Hi,

LieutenantHacker wrote:I never say never, so I will attempt things my own way.

Humans will never be able to walk through solid concrete. You will never exceed the speed of light. An OS that allows applications to run in real mode will never be secure.

Please waste years attempting all these things (I'd recommend doing them in the order listed); even though anyone with even the smallest amount of common sense knows that it's completely pointless and that failure is guaranteed, simply because you never say never.


Cheers,

Brendan

Brendan wrote:Hi,

LieutenantHacker wrote:I never say never, so I will attempt things my own way.

Please waste years attempting all these things (I'd recommend doing them in the order listed); even though anyone with even the smallest amount of common sense knows that it's completely pointless and that failure is guaranteed, simply because you never say never.

Don't mention Real Mode on OSDev or you get yelled at by the seniors.

Multitasking in real mode is not impossible but it's general very difficult to do.
Real Mode is great for writing simple operating systems but perhaps not designed with multitasking in mind.
However you'll learn better by doing rather than discussing, so by all means give it a go. I certainly did...

Of course it can be done. I have done a production level multitasking "kernel" for real mode that is running in some 500 installations. However, this is not really a kernel, but rather an object module that contains the multitasking functions for the application. That's a better alternative since isolation between OS and application cannot be achieved in real mode anyway.