OSDev.org

omarrx024 wrote:The PIT does the task switching.

Actually it doesn't, lol.

ExeTwezz wrote:Actually it doesn't, lol.

Actually, it does. I have my PIT IRQ handler do the task switching.

Which still means the PIT itself doesn't do the actual task switching.

Combuster wrote:Which still means the PIT itself doesn't do the actual task switching.

Oops, my mistake. I meant the PIT IRQ handler.

Actually the pit irq handler doesn't do the task switching but the cpu

Roflo wrote:Actually the pit irq handler doesn't do the task switching but the cpu

Hehe.

omarrx024 wrote:Multitasking support!
The shot shows two tasks running. The first task prints "1" and the second task prints "2." The PIT IRQ handler does the task switching.

I thought your OS used BIOS calls. How exactly do you use task-switching? The BIOS isn't pre-emptible..?

bace wrote:I thought your OS used BIOS calls. How exactly do you use task-switching? The BIOS isn't pre-emptible..?

I installed a custom IRQ handler for the PIT. This custom handler checks for running tasks and switches between them. And besides, task switching doesn't depend on GDT, TSS and other 32-bit stuff. There is nothing wrong with creating your own custom structures and things. In fact, it is even more customizable and easy this way. Who ever said that multitasking cannot be done in 16-bit mode?

No, I mean, how do you preempt tasks running BIOS code? This has nothing to do with you being in real mode.
You can't just stop a BIOS call midway, call a few others, and expect it to return to the original one (as far as I know). Is that what you're currently doing?

bace wrote:No, I mean, how do you preempt tasks running BIOS code? This has nothing to do with you being in real mode.
You can't just stop a BIOS call midway, call a few others, and expect it to return to the original one (as far as I know). Is that what you're currently doing?

Yes. Whenever a PIT IRQ occurs, I save the return EIP address and save SS and SP. Then when my PIT IRQ handler returns and the other running tasks finish running, it saves the state of other tasks and restores the stack of the BIOS code. It then jumps back to the BIOS code.
Come to think of it, the code that tests my multitasking (the code that prints "1" and "2" as seen in the screenshot) uses BIOS INT 0x10.

omarrx024 wrote:

bace wrote:No, I mean, how do you preempt tasks running BIOS code? This has nothing to do with you being in real mode.
You can't just stop a BIOS call midway, call a few others, and expect it to return to the original one (as far as I know). Is that what you're currently doing?

Yes. Whenever a PIT IRQ occurs, I save the return EIP address and save SS and SP. Then when my PIT IRQ handler returns and the other running tasks finish running, it saves the state of other tasks and restores the stack of the BIOS code. It then jumps back to the BIOS code.
Come to think of it, the code that tests my multitasking (the code that prints "1" and "2" as seen in the screenshot) uses BIOS INT 0x10.

try doing that while accessing the harddrive could destroy your computer (depending on exact instant the PIT interrupt occurs) even if it doesn't, it definitely won't work correctly -- best case, the BIOS function will fail (return carry set) worst case the computer will be physically damaged, more likely it will succeed (return carry clear) but the expected action won't happen, and something else will instead (like reading or writing the wrong disk sectors, causing major data corruption)

"int 0x10" is not actually part of the BIOS -- its part of your graphics card (and if you have discreet graphics, it is physically located on the graphics card) -- there is a big difference between the video BIOS and the system BIOS... and even here you are only using it in a trivial case

the BIOS functions perform no locking, nor do they disable interrupts during critical hardware accesses, therefore they cannot be simply "swapped out"
the BIOS also relies on the PIT for critical timing while accessing hardware, so if you switch tasks during a timing-critical PIT IRQ, the timing for hardware information will be wrong, causing incorrect results, failure, or in worst case potentially damage to the hardware (note this also means if you hook the PIT IRQ you must also chain-call the BIOS PIT IRQ so that any BIOS hardware functions can track the timing)

edit:
it is perfectly possible to do multi-tasking in RMode, it is also perfectly possible to do multi-tasking on an OS that uses BIOS -- but you need to make sure you never switch tasks while in BIOS code (this could theoretically be done very simply by checking the return CS:IP if it is in BIOS region, don't switch)