Software task switch - interrupted ISR

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.
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:

Re: Software task switch - interrupted ISR

Post by Combuster »

suslik wrote:OK, I think to make something like this: (...) is not good, since when ISR is time consuming I lose some timer interrupts
Not quite, because even if an IRQ is running too long with interrupts enabled, you might just as well lose interrupts. The only difference is that they have to be of a lower privilege. You don't want for instance your mouse to randomly stop working because of a design issue like that.

Also, I don't remember exactly, but add/sub instr-s don't have implicit lock. Why not inc/dec?
Read-modify-write operations are not atomic respective to other logical cores without the bus lock, and add/sub are no different than inc/dec (only xchg is atomic without lock due to history). The IRQ nesting counter is per kernel stack. Other processor cores have no business modifying other cores' counter so a lock is not necessary.
Regardless of design, you should always use interrupt gates.
Interrupt gates are for when you need to run some code uninterrupted before it is safe to nest other IRQs. That is not the same as "always"
rdos wrote:Because inc/dec don't update flags.
That's absolutely not true.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
rdos
Member
Member
Posts: 3308
Joined: Wed Oct 01, 2008 1:55 pm

Re: Software task switch - interrupted ISR

Post by rdos »

Combuster wrote:Interrupt gates are for when you need to run some code uninterrupted before it is safe to nest other IRQs. That is not the same as "always"
I meant always in the context of IRQs. In other cases, it might be better to use other gate-types.
Combuster wrote:
rdos wrote:Because inc/dec don't update flags.
That's absolutely not true.
I should have stated: "inc/dec don't update carry flag".

From Intel manual:
Subtracts 1 from the destination operand, while preserving the state of the CF flag.
The destination operand can be a register or a memory location. This instruction
allows a loop counter to be updated without disturbing the CF flag. (To perform a
decrement operation that updates the CF flag, use a SUB instruction with an immediate
operand of 1.)
Since my code used the CF flag, it could not be changed to use inc/dec as those won't affect CF.

BTW, it was correct to use jnc, because the initial value was -1. When the initial value is restored, CF becomes set, and then there should be a test for pending task switches.

It is possible to set initial value to zero, and use jnz, but then the first sequence (sub int_nesting,1) would not return with ZF set when done the first time, something I rely on at other places, while the CF would be set both on first entry (in the entry code), and on last exit (in the exit code).
Post Reply