X86 Asm - CLI, STI
AFAIK you can still call software interrupts "int xx" with the interrupt enable flag clear. Similarly, exceptions (such as divide error) will still occur. CLI disables hardware interrupts only.
It can still do the right thing even within an interrupt handler?
I didn't think that'd work.
Ho hum.
I didn't think that'd work.
Ho hum.
Quote:
It can still do the right thing even within an interrupt handler?
I didn't think that'd work.
I don't see what the problem could be.
How would the state of the interrupt flag affect what the interrupt handler could do? It affects only whether or not the handler is entered.
As previous posters said: CLI/STI are only interesting to kernel mode programming.
CLI for a long time (> 1 ms) will mean that other things that need to run (mouse movement, screen sync, audio buffers, etc) will not get time when they need it, so your system will become more unreliable. This is a major reason Win9x/ME can't be used for much; most drivers use CLI willy-nilly.
CLI can ensure atomicity (no other code will run and compete with your data structures) if you're guaranteed to be on a single-CPU system. If you can be on multiple CPUs (including HyperThreading enabled) then you need to first CLI, and then compare/exchange some memory location until it was zero, and you set it to 1; this is known as a spinlock. Set it back, and restore interrupts when you're done. Acquiring a spinlock from within an interrupt handler is possible, but of course, you should RESTORE interrupts, not ENABLE them when un-acquiring the spinlock, in the case they were disabled when you acquired it in the first place.
However, it's more portable to just use the kernel spinlock primitives, and do as much as you can out of a DPC rather than directly from an interrupt handler.
CLI for a long time (> 1 ms) will mean that other things that need to run (mouse movement, screen sync, audio buffers, etc) will not get time when they need it, so your system will become more unreliable. This is a major reason Win9x/ME can't be used for much; most drivers use CLI willy-nilly.
CLI can ensure atomicity (no other code will run and compete with your data structures) if you're guaranteed to be on a single-CPU system. If you can be on multiple CPUs (including HyperThreading enabled) then you need to first CLI, and then compare/exchange some memory location until it was zero, and you set it to 1; this is known as a spinlock. Set it back, and restore interrupts when you're done. Acquiring a spinlock from within an interrupt handler is possible, but of course, you should RESTORE interrupts, not ENABLE them when un-acquiring the spinlock, in the case they were disabled when you acquired it in the first place.
However, it's more portable to just use the kernel spinlock primitives, and do as much as you can out of a DPC rather than directly from an interrupt handler.
I can't see how CLI / STI are useful even in kernel-mode programming, because on a multiprocessor system (or hyperthread), they don't actually stop interrupts from interrupting the other processor.
Instead just use proper locking as specified by the OS to protect whatever it is you're trying to do with interrupts disabled.
Having another processor messing with things is at least as disruptive as having an interrupt happening - and you can't stop it with CLI.
Not to mention the fact that these are ia32 instructions which don't even exist on other CPUs (although of course they have equivalents).
Just use kernel-mode locks for your OS.
Mark
Instead just use proper locking as specified by the OS to protect whatever it is you're trying to do with interrupts disabled.
Having another processor messing with things is at least as disruptive as having an interrupt happening - and you can't stop it with CLI.
Not to mention the fact that these are ia32 instructions which don't even exist on other CPUs (although of course they have equivalents).
Just use kernel-mode locks for your OS.
Mark
Quote:Original post by bakery2k1
Yes. The interrupt controller will keep the interrupt line of the CPU asserted until it receives an End-Of-Interrupt signal, which will only be sent by the interrupt handler.
Ok. Does the EOI signal come about from the iret instruction (at the end of the interrupt handler)?
Quote:Original post by bakery2k1
LessBread, are you trying to write code to run in kernel mode?
The code is already written.
Quote:Original post by LessBread
Ok. Does the EOI signal come about from the iret instruction (at the end of the interrupt handler)?
I vaguely remember something like outputting 20h to port 20h... it's been MANY years, so don't count on that being accurate. The documentation of the interrupt controller chip is probably the best place to look (or perhaps a quick glance at Linux).
Quote:Original post by hplus0603
As previous posters said: CLI/STI are only interesting to kernel mode programming.
CLI for a long time (> 1 ms) will mean that other things that need to run (mouse movement, screen sync, audio buffers, etc) will not get time when they need it, so your system will become more unreliable. This is a major reason Win9x/ME can't be used for much; most drivers use CLI willy-nilly.
CLI can ensure atomicity (no other code will run and compete with your data structures) if you're guaranteed to be on a single-CPU system. If you can be on multiple CPUs (including HyperThreading enabled) then you need to first CLI, and then compare/exchange some memory location until it was zero, and you set it to 1; this is known as a spinlock. Set it back, and restore interrupts when you're done. Acquiring a spinlock from within an interrupt handler is possible, but of course, you should RESTORE interrupts, not ENABLE them when un-acquiring the spinlock, in the case they were disabled when you acquired it in the first place.
However, it's more portable to just use the kernel spinlock primitives, and do as much as you can out of a DPC rather than directly from an interrupt handler.
Ok. That's helpful. I see now why it was in the code and why it was frowned on in the ng. Thanks. Thanks also Dr. Pizza, bakery2k1 and markr.
Quote:Original post by Namethatnobodyelsetook
I vaguely remember something like outputting 20h to port 20h... it's been MANY years, so don't count on that being accurate. The documentation of the interrupt controller chip is probably the best place to look (or perhaps a quick glance at Linux).
Ok. Maybe I'll do that.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement