So, I have a code, that loads and go to LongMode. Start IRQ0(Timer) and mainloop (shell). But how to make multitasking, without TSS (w/o hw multitasking in AMD64)??? I searched an software multitasking, but nothing. I don't like C++, so work with Linux/BSD sources is wery hard for me. Please, help with simple realization of SOFTWARE MULTITASKING realization, (may be x32... I will rewrite it for x64). May be only good doc's...
Thanks for ANY information.

Multitaskting or multithreading? I suggest you start with multithreading

The basics are simple, you need a CONTEXT structure where you store the per-thread register state (later you'll need more per-thread information, like a backlink to the PROCESS it belongs to). On a context switch, for simple threading, you simply select a new CONTEXT structure and load register state from it - voila!

In a flat unprotected OS multi-threading and multi-tasking are much the same thing. So if you want to start simple (which is recommended) then don't go for a protected OS with task isolation etc. just use a simple structure to save the CPU and FPU states and have a scheduler select which state to run during each time slice. For any shared resource use access locks to block other threads from entering.

multitasking:
define work space.
define code and data segments.

multitask with timer:
when timer0 = taskswitch.
int timer


multithreading with multitasking:


this way is not architecture ddependant.

f0dder, thanks, but I need multitasking ))). In 32bit OS I already had hardware multitasking, but question in AMD64 MT...

Ok: I can do CPU context switch - this is not a problem. But question is - how with software MT I can do CPL0..3 levels for processes, isolation, ..., understand? I repeat: hw mtasking - not a problem. need software.

Ok. I downloaded AMD tutorial - will learn now )))
But if someone have sources - please... )))

I would sugest you look at this code to give you a idea and convert it to long mode

http://www.dex4u.com/ASMcompo512b/nanoos2.zip

it's not that, but source very interesting, some good ideas.
BTW, dex4u - I saw your OS - very fine! )

-- ------------------
Thanks, I already find something in AMD tutorial #24593.

narada, what do you mean by software vs. hardware multitasking?

Even on 32bit OS where you could use TSS, you generally wouldn't do that, because it's much slower than software context switching.

And for 64bit mode, you can still do ring3/ring0 split and use paging for isolation... what is it specifically you're having trouble with?

Long mode doesn't support HW multitasking anymore. You must use SW multitasking (which is even faster than old hw multitasking in 32 bit world).
The principle is quite simple:
- timer interrupt (a part of kernel code) ticks at some period
- when timer hits, the running program is interrupted and its SS, RSP, RFLAGS, CS, RIP are saved in the kernel stack
- at this point, your OS decides whether to leave the interrupted program to continue (just do IRETQ instruction) or to change task
- if changing task, OS saves the rest of registers of the interrupted program, reloads registers of new program to execute. Registers SS, RSP, RFLAGS, CS, RIP of new program are placed into the kernel stack and the new program resumes just after doing IRETQ in kernel which reloads SS, RSP, RFLAGS, CS, RIP registers with the values of new program.

to narada
without TSS - I think it is not good way. The kernel (including timer interrupt) needs to know how to switch kernel stack during interrupt (ring3->ring0 switch) and this is defined in TSS. TSS can be much simpler than in HW multitasking. Minimal TSS requires perhaps only RSP0 value (RSP when switching from higher rings into ring0 kernel), but TSS is really good place where to store the rest of registers too. You can arrange register positions as you like (HW multitask has defined certain positions for registers)

Imho it's silly that hardware context switching isn't implemented, and implemented in a fast way. After all, it's something that happens all the bloody time on a modern OS. But that's a pretty common thing with x86, it lacks a bunch of useful features, and parts of the instruction set can be done faster with multiple simpler instructions - I don't really get that, since one complex instruction could easily be made to generate the same µops as several simple? :-s

Feryno, why you wrote "RFLAGS" - I learned AMD64 tutorial, EFLAGS still 32bit in AMD64LM...

to narada - yeah, you are right, the flags register is some "hybrid" - is 64 bits wide but uses only low 32 bits (just like EFLAGS) and the upper 32 bits are all zeros. Perhaps sometimes in the feature the zeroed bits become usefull for something...

when you push this register (pushf instruction) in long mode, all 64 bits are pushed into the stack

when you pop this register from stack (popf), 64 bits are loaded into flags register from the stack

there are only 2 instructions how to reload the whole flag register from the stack: popf, iretq
(+ some to modify only 1 bit of flags like clc, sti, ...)
I think doing iret (db 0CFh) instread of iretq (db 48h, 0CFh) in long mode reloads only 32 bits of flags register from the stack (and only 32 bits of IP register - hence EIP instead of RIP)

All this day learned linux 2.6.9 kernel sources for x86_64... How I hate C/C++!!! )))

I haven't looked into the task switch algorithm but I imagine the reason it is slower is the same as for instructions like 'loop'. Naively one might expect 'loop' to generate two µops (dec ecx/jnz target) but the problem is that loop has a restriction of not altering the flags, registers (except ecx) or memory so the normal µops can't simply be inserted into the code stream, the microcode has to use either more µops or slower µops. Scale that up to a complex task switch and things start to happen slower.

revolution: hadn't thought of flag dependency thing for LOOP... as for context switching, it would make sense to use a little die space to add in fast hardware context switching, since it's used all the time.

Actually it is not used all that often. Most desktop OSes switch at the fastest rate of ~ 30ms (IIRC) so the occasional task switch instruction executed once per 30ms (worst case) is a tiny overhead compared to the total of all the other instructions executed.

AMD64 documents refer to rflags instead of eflags.

regards,
Mac2004