OSDev.org

heyo

i have come to the part of os-creation where i should decide whatever i should use a tss or a own taskswitching model.

this part of the os (tss/own) wasnt very important when i was planning on the os-model, so i simply skiped it. but now, i cant decide if i should use a tss or create a own taskthing..

if i use a tss, the processor will make the switch quiet and easy, but i will have to follow its rules.
if i write a own taskthing, i will have to optimize it very well, pairing instructions in u / v pipes etc.. and that takes time, and i dont know if this is faster than using a tss!

now, my question is: should i use a tss or write a own?
wich one is fastest?

- - - - - - - - -

the os i am writing on is named snafu and is to be written in 100% asm.. or, atleast the kernel is suposed to be. i want it to be a distributed os with un/loadable modules.. so that you may, for example, add suport for a new filesystem without rebooting. i am also trying to make it as small as possible (the snafu-pic is 12,5kb large right now).. if you want to help me or just ripp code or whatever, goto my homepage: http://home.swipnet.se/smaffy

Hi,

In my OS, I use TSS and I just can say that it is easier than switching the context by yourself.

Some designers think that using a TSS is slower than saving and restoring the registers but I am not very sure. The main advantage of switching the context is that it is CPU independant ( the process not the content ), so in your kernel doesn not use built-in CPU features.

I think that the built-in task switch mode of x86 processor take part of the full processor protection system. If you try to shortcut this part, you lose something.

There are some advantages of using TSS :

- Better protection ( I/O map + busy flag )
- Fpu flag management automatically set ( CR0 TS )
- Possibility of using task gate

I think there are others advantages and disadvantages, but I made my choice.

Roswell

oh.. i see.

there is one thing that i am curious about.. how is the fpu-registers saved, or are they simply ignored by the tss?? it seems that the tss dosnt suport them at all (i could ofcorse just resize the tss and include the fpu-registers by saving them by myself..)

and how should i switch task for best performance?

In fact, you have to save the FPU by yourself but the processor helps you.

When you make a task switch using a TSS, the CPU sets the task switch flag (TS) to 1. If you have correctly filled CR0, the first FPU instruction will cause an DNA ( Device Not Available ) Exception. You must define a handle here that will first clear the TS ( CLTS instruction ), save the FPU (fsave) for the last using task, and restore (frstor) the FPU context for the new task.

If a task never use the FPU, you won't have to switch the FPU context.

To switch a task, simply jump to a TSS .

Here is the piece of code I use for the FPU

Ex_7_Handler:
   pushf
   cli
   push   eax

; Clear TS before fsave, or it will cause a double fault
   clts

   ;   Save previous
   call   _getPreviousFPUStatePtr
   cmp      eax,0
   je      X7_nosave

   fsave   [eax]

   ;   Load New
   call   _getFPUStatePtr
   frstor   [eax]

X7_nosave:
   pop      eax
   popf   
   iret


Roswell

I'm going to use TSSes in my OS. Yes, to do a TSS task switch requires about 800ish ticks, but at the speed of todays CPUs, that's a very small sacrifice for how much easier it is than doing it without TSSes.

K.J.

K.J. wrote:I'm going to use TSSes in my OS. Yes, to do a TSS task switch requires about 800ish ticks, but at the speed of todays CPUs, that's a very small sacrifice for how much easier it is than doing it without TSSes.

I'd say the opposite: that it's easier to use software switching. If you use a TSS, you have to deal with:

• setting up descriptors in the GDT
• swapping between two TSSs to overcome the 8192-descriptor limit
• debugging your task switching code -- if any part of the intricate task switch sequence breaks, you get a vague TSS fault

If you use software switching, you get to write all of the task switch code yourself, so you know what the CPU's doing at a given moment. Also, if anything wrong happens (e.g. you give the wrong value for a selector), the CPU will fault at the right line (if you're using Bochs you'll get detailed crash information); you don't get this with TSS switching. Software switching allows for nested interrupts, too: if an exception occurs inside your kernel, your software switching code will just push another set of registers onto the stack. A TSS-based interrupt system will just overwrite the last set.