OSDev.org

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.

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).