0

I have the following code which I was expecting not to work:

cli
lgdt [gdt_32_descriptor]

mov ah , 0x0e 
mov al , 'f'
int 0x10

I was expecting after using cli instruction, that int 0x10 would not work. Though I normally get an f printed. Does this mean cli didn't clean bios interrupts?

phuclv
  • 37,963
  • 15
  • 156
  • 475
Νίκος Αντωνετσής
  • 65
  • 7
  • 4
    That is a software interrupt, `cli` has no effect on it. To quote the manual: _" Clearing the IF flag causes the processor to ignore maskable **external interrupts**."_ (emphasis mine). What did you expect to happen, anyway? Surely silently skipping an `int` instruction would be bad, and you can hardly block execution waiting for interrupts to be reenabled for obvious reasons. – Jester Mar 03 '22 at 23:34
  • 3
    In one sense, it is a misnomer to call the `int` instruction an interrupt. Yes, software interrupts share virtually all of the the same exception mechanism as external interrupts, but they occur under program control; they are requests for supervisor action, without which the program cannot continue. There are no better alternatives to servicing the program's request. As Jester says, these cannot be ignored, as the program cannot continue without supervisor action. The operating system could choose to halt the program, which would be weird as that would happen after taking the exception! – Erik Eidt Mar 04 '22 at 00:05
  • That could lead to the situation of being impossible to exit a program by a system call, because there might not *be* any code following the skipped instruction. – Weather Vane Mar 04 '22 at 20:39

0 Answers0