I am attempting to make a 32bit pmode paging preemtive operating system (mainly for bragging rights and because the best way to know how something works is to make it).

I am formulating a plan that implements software based task switching where I use a timer to call an interupt that switches the stack and registers per thread as well as switching the page directory per process (user space->process->threads).

The interupt handler does:

Swaps the page directory back to the kernels page directory
(thread and process management structures exists only in kernel address space).

Saves all registers to the currently running thread's management structure and sets a time for the thread to wake up.

Enters a loop searching through the thread list inside of the process management structure for a thread whose wakeup time is less than the current time then loads the registers from this thread's structure and loads the page directory from the parent process's structure and finally exits the interrupt hander.

-If all threads inside of this process have been polled, we increment the process index and load that process's management structure and start the thread loop again.

-If all processes have been polled we start back at process 0 (kernel) and start the thread loop again.


Would this work?... Would this be efficient?

Will I need to change the tss values to put the kernel process in ring 0 and put the user mode processes in ring 3?
-if yes, does that still work in long mode when I move on in the future?

Hi Gizmo!



Unfortunataly hardware multitasking is not supported in long mode. So the AMD64 manual says.
If you want to proceed to long mode as well, you'll have to do multitasking with software.

In others words: if you choose do PM multitasking by using the hardware, you would have to write LM multitasking all over again without the hardware.

regards
Mac2004

Thats what I am doing, software multitasking using a timer.
I just need reassurance that my plan would work thats all.

Have you obtained AMD64 and corresponding Intel system programming manuals? Reading them is very useful.

regards
Mac2004

On my opinion your concept will work on both, PMode and LMode. The only thing you should think about is a priority of threads, so that not each of them gets the same proceeding time.

The intel docs only discuss hardware task switching though- they say you have to use software task switching in long mode but offer no suggestions or examples.

I could adjust priority in real time perhaps by adjusting the sleep time issued to each thread after the timer interrupt thread switcher thingamabob, larger sleep times would devote less time to a thread leaving more time for other threads.

A question about unused processor cycles:
Lets say all of your threads have been put to sleep and their sleep time hasn't passed yet, how do you avoid waisting cpu cycles?
set timer and halt, when timer interrupts run task switcher again?
(for example battery saving mode on a laptop, or instances where the user is staring at a blank desktop and only certain drivers are running in a low priority message driven mode)

Looking at windows task manager you will find a "Leerlaufprozess" (I don't know the english equivalent - sorry). That's why it seems to me that there is a waste of CPU cylces in Windows, too. But I don't know how you should make the CPU staying cool and not wasting power while no task needs it.

Maybe someone else has a good suggestion on what the CPU does when it does nothing.

It is System Idle Process. However this pseudo process spends its slices in halting state (HLT instruction) or anything else but it doesn't keep the processor busy, otherwise you would notice high CPU temperatures always and certainly that doesn't happens.

As I said above, I'm using a separate page table per process.

I'm wondering if I would even need to have paging for the kernel itself, if I
disabled paging during interupts, task switching, and other kernel sections to simplify things would it be a good idea since my kernel won't be big enough to benefit much from paging. (the processes will have paging, just not the kernel)

Also, if I'm using stack based task switching, do I need to create a single tss for the entire system or can I just avoid it?
... and in long mode?

I wouldn't want to keep turning paging on/off... as for "my kernel won't be big enough to benefit much from paging.", protecting is benefit enough

Iirc you need a single TSS to handle exceptions properly, but wouldn't know about long mode.

I heard that paging needs to be on for LONG mode.

That's right. But it is no problem. If u setup the pagetables continuous, you will not notice it in your OS. Than you have a real flat model. What I don't understand is, why segmentation is no longer supportet in Long mode.

Because it's not needed. For things that really can use segments (thread-specific info) you have FS and GS, that still work in 64bit mode.

From what I understand, you can have just as good protection to segmentation by simply making separate page directories per task and leaving out everything you don't want that task to mess with or use the page flags.

(I have to use the from what I understand phrase because I just started learning asm last week...I guess you can say I am the guy who learns how to swim by diving off niagra falls in a barrel.)

Because segmentation hasn't been necessary nor desirable ever since paging was introduced with the 80386, but was kept because Intel wanted to be 100% backwards legacy compatible.


Paging gives better and more fine-grained protection than segmentation, and can be used for other stuff as well

So why do you have to Setup descriptor-tables when they are not needed. On my opinion they should remove ALL segmentation-stuff ore none of it. If it was available, it would be the choice of the developer.

Because they wanted legacy support.

Intel should've scrapped their existing design with the 80386 and made some fundamental changes, it's the last chance they had, really... but they didn't, and after AMD insisted on introducing x86-64, we're stuck with the x86 patchwork for god knows how long.

f0dder, you're not "stuck" with anything, but you may not get any help / support from most people who "want" to use such things (even if you disagree). It's just one more thing to learn / fix and you have to rewrite everything. Sorry, but that sounds annoying. (Besides, there may be hardware support for 16-bit x86 stuff but nobody hardly uses it these days. But I guess you think such support "slows down" the computer, heh, doubtful.)

BTW, IBM had a huge foothold in the 286, making OS/2 support it explicitly for quite a while because they (supposedly) had sold a bunch of 'em. So, for someone like Intel to just stop making compatible processors, that would've slowed down the "computer evolution" tremendously! (Most people actually like the 386's new features and don't sweat it.)

It's not so easy to throw away everything old. People will complain (call them what you want, "Luddites" or just people who want stuff to keep working).

Compare the Atari 5200 (all alone) vs. Atari 7800 (also ran 2600 stuff). Or PS2 (also plays PS1) vs. XBox (uh, only their stuff?). Which would you rather have?

Oh yes, people only want their machines (apparently) run faster and their software still working. If you work for money, it's nearly impossible to introduce something new, especially in these days. Better to stick with one of the worst ideas born in the seventies: the x86 instruction set.
Does anybody know the status of a (quite good) idea born in 1997, that is EPIC instruction set and Itanium? This was developed with HP and would have been a fundamental change (I was surprised Intel had done something interesting), but I believe all people out there are still sleeping in their consumistic dreams and few of them are interested in it.

Edit after rugxulo: Itanium is fully compatible with today's processors, it's just that it's not particularly fast at emulating (especially the first versions). It could have been the chance to kick in something new without losing what we have now.

rugxulo: 16bit legacy support might not "slow down" things, but it does require a bunch of transistors, and complicates the architecture. I would expect anybody that have played with kernel development to agree that intel should at least have dumped 286 pmode support in their 386 chips, instead of having such horrid data structures.

Yeah yeah, OS/2 and Win3.x supported 286pmode, cry me a river. The amount of legacy apps was pretty small compared to the huge mountain we have today, making it more or less impossible to abandon ship.

Microsoft made the same mistake with NT, they based the win32 API on the win16 API instead of thinking things through a bit, and keeping win16 solely as an emulated subsystem.

pfranz: original problem with the Itanium was they did x86 emulation in hardware, adding tons of complexity to the design (and transistor count), while in the end software emulation turned out to be faster... that, and of course pricing the chips solely for the high-end market, keeping it from getting a real break-through.

I had hoped that the move towards 64bit even on the desktop would mean a chance for a new system with a cleaner design (although not escaping windows), but AMD ruined that with x86-64.