OSDev.org

i think it has been discussed before, but roughly, when you use hardware task switching, you can't prevent the CPU from clearing the whole page mapping cache (the so-called Translation Lookaside Buffers), which will make all further memory reference pretty long as it'll have to fetch the page directory entry and the page table entry from memory before it actually can read/write your memory location.

Considering the frequencies difference between memory references and instructions execution, this make the switch veery slower when you stay in the same process (i mean, in the same address space).

When you come to switching from one process to another, then the execution time will be roughly the same, maybe a bit faster for TSS if you have very different process (using other segments, a new LDT, other I/O bitmap infrastructure, etc.)

Another thing that remains fuzzy for me is how MMX/FPU state is preserved by software switching. Intel guyz had a special exception raised when you try to access the FPU register bank after a switch, so that you can write back the register content to the outgoing process and load the content of the ingoing process. As this is made only on FPU access attempt, it save switch time when you move into a process that uses no FPU.

How do one implement this with software switching ? manually setting TS bit ? i'm not sure you can ...

Pype:

To save the FPU state is dead easy.

Where you PUSH EAX, PUSH EBX etc to save thread context, insert an FXSAVE instruction.

When you POP EBX, POP EAX etc to restore thread context, insert an FXRSTOR instruction.

Thats my plan anyway. Seems logical to me. All P3s and Athlons support FXSAVE / FXRSTOR so I'm not bothering to support older processors.

And also you can get more complicated, to only save / restore the FPU state when it has actually been used. Thats an optomisation which I'm not worrying about now.

thanks, guys. i think i'll stick with hardware task switching for now, since it's easier to do, but can you tell me if i need to make my next label a tss? that's what i assumed from the fact that it wasn't loading the right code, plus what pype said about the task selector being automatically initalized by the jmp to the first task.
thanks again ^^;.

what do you call the "next" label ?

i was referring to the last label in init.asm . it's the label that is jumped to at the start of pmode.

hmm. no, i would not recommend you to replace your "jmp CODEOS:start32" by some "jmp CODETSS:0". That would be hard to set up and not even useful.

Simply jump to a valid code segment where you will optionnally fill ESP0 and SS0 of a task and do a "LTR <tss-selector>" when done.

that first TSS will only exist while initializing the kernel, do not try any "jmp <other-tss>" until you have fully-tested exception handlers (because there are sooo many possible cause of failure when switching tasks , thus certainly don't jmp to a tss before you enabled the IDT (which cannot be done prior "jmp CODEOS:start32")

-- btw, in the init.asm of hakwareOS-1.1-1.zip, it looks like you're jumping to segment 0 !??
-- also note that "mov ax,[systemtaskselektor]" will do nothing good. do "mov ax,systemtaskselector" instead...

thanks.