Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
BareMetal OS is currently a mono-tasking system but I would like to add multitasking.
I would like each Core to map this first 2MiB page to the kernel and anything above that would be allocated from physical memory for a program. This would not be true multi-tasking but more of a one program per Core system.
Can this be easily accomplished by creating a separate PML4 for each CPU Core?
BareMetal OS - http://www.returninfinity.com/
Mono-tasking 64-bit OS for x86-64 based computers, written entirely in Assembly
Can this be easily accomplished by creating a separate PML4 for each CPU Core?
Yes. It's more usual to have a PML4 for each process and for each core to load the PML4 for its current process. But your idea will work fine. Something to consider though is that if one core modifies its kernel mapping, the other cores will need to update their mappings too.
If a trainstation is where trains stop, what is a workstation ?
Thanks for the information. I won't require a separate PML4 for each process since the system will only support 1 process (program) per CPU Core. For instance if the computer has 4 CPU Cores it will be able to run 4 programs concurrently.
This should be simple enough to implement.
-Ian
BareMetal OS - http://www.returninfinity.com/
Mono-tasking 64-bit OS for x86-64 based computers, written entirely in Assembly
Why just one task per core? Wouldn't that lose time because of IRQs?
At a basic kernel level, I think we all have found limited use for multitasking. So maybe one of the easiest ways to start an useful multitasking is to perform several hardware detection tasks just for the sake of experimenting with the multitasking infrastructure.
For instance, I think a test kernel could feature a task that detects all ATA/ATAPI devices and shows its results all over again and shows something like the number of devices in a section of the screen, other task that retrieves the time in another section of the screen, other that maybe tries to play some simple WAV over the PC speaker, and other tasks that just move around text-mode squares or actual animated GIFs, etc, in the screen.
That should be enough to test different preemptive/cooperative, real-time multitasking, for a start.
Remember that the term multitasking is very general. Multitasking graphics, filesystem, sound, and other miscellaneous tasks have different implementation requirements and one has to be able to realize how to integrate them in the same system properly.
______________
Also, as I see things, the first multitasking could be "manual" multithreading of one same application, and from there one could add other types of multitasking until it can be a true "inter-process" multitasking.
For instance, a basic multithreading could be having a main function and have different screens for which we could call functions from an user menu, and this function could have, say, a floppy formatting thread and a progress bar thread.
Everytime we format a chunk of the floppy, with yet another function, we would call a progress bar updating function right after formatting the chunk, inside a loop.
I can't think right now of a simpler "manual multithreading" as this.
Well it took AMD and Intel to get up to eight cores, but be the time we have 32 cores inside each PC, I wonder whether this might not be the standard method of multi-tasking, with time slicing being a relic of the "olden days."
Casm wrote:Well it took AMD and Intel to get up to eight cores, but be the time we have 32 cores inside each PC, I wonder whether this might not be the standard method of multi-tasking, with time slicing being a relic of the "olden days."
You could have a system in place so that each process runs on its own core if there is close to the same number of processes as cores. If there are less processes, then several cores could run different threads of a process, and then if there are more processes than cores, switch back over to the standard time-slicing system. Of course, this would only work if you had something like 32 or more cores. Or on many main OS's, like 128.
I still think that some form of multitasking cam still be beneficial for each single core. Even if it's regular multithreading.
Think about how a virtual machine, and also a GUI, and many other things would require at least proper multithreading. I don't think it would be good to limit to 1 only thread altogether per core.
