CLI/STI

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.
Post Reply
DarylD

CLI/STI

Post by DarylD »

A quick question for those in the know here.

I have been reading my OS book trying to figure something out. When a CLI instruction is executed all maskable interrupts are disabled until the next STI, yes?

Are the interrupts held back or blocked. I.e. if a timer interrupt would have occured when interrupts are disabled does it cause an interrupt as soon as STI is executed?

Basically put, if I disable interrupts, will it stop hardware/software interrupts but not actually miss them?
jrfritz

Re:CLI/STI

Post by jrfritz »

I think it disables all ints from even occuring...
pskyboy

Re:CLI/STI

Post by pskyboy »

I think you'll find it doesn't so much as stop them happening as stop them being seen so to speak.

Basically it masks the interrupts which means it makes it so that when one occurs it doesn't actually register. its kind of like having a headache or extreme pain of some sort when you take some pain killers you no longer feel the pain. But the signals for the pain are still being sent so you effectively lose those pain signals the same is true for the interupts.

This is why it is recommended any operation ocurring while interupts are off is fast.

Peter
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:CLI/STI

Post by Pype.Clicker »

when interrupts are blocked (with a CLI), any hardware Interrupt ReQuest will be kept on the Programable Interrupt Controller (or its Advanced version : the APIC) so that when you STI, the interrupt is delivered (but with a little delay).
This means that relying on the timer interrupt to keep your clock on time will not be slowly drift...

But watch out! the PIC only remembers ONE interrupt request. If you block the interrupts for so long that 2 IRQ for the same device are risen up, then you will be interrupted only once ... which may trouble you while reading the keyboard, for instance (you'll have a scancode pending that you won't be able to deliver).
DarylD

Re:CLI/STI

Post by DarylD »

Thanks all, thats what I suspected, but wasn't sure. I didn't realise it will only hold one IRQ in queue though, that shouldn't be a problem though for what I have in mind.

I think I might try and work in a system of delayed interrupts rather than blocking entirely. I.e. if a timer interrupt occurs the kernel will make a note of it and then execute it when the kernel leaves a critical section.

PS. If anyone is interested I have posted up the latest version of my test code on my website it anyone wants to have a look to help them with thier own code. Its far from complete but does do software task switching, IDT setting up and interrupt handling and has some code for handling modules/memory and the like.

http://homepage.ntlworld.com/daryl.dudey
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:CLI/STI

Post by Pype.Clicker »

i personally use CLI/STI for the smallest possible amount of time (i.e. while accessing a semaphore, for instance: clicker CLI before it starts checking if the semaphore is available so that the current thread don't get preempted between the time it sees the semaphore isn't free and the time it has put itself in the wait queue...)
Post Reply