Page 1 of 1

Clearing interruptions in a bootloader

Posted: Thu Nov 19, 2020 11:01 am
by Scorpion197
When building a bootloader, we have to clear all the interruptions. Why do we have to do such a thing ?

Re: Clearing interruptions in a bootloader

Posted: Thu Nov 19, 2020 11:06 am
by MichaelPetch
You don't have to and it all depends. If you are in real mode the entire time you can keep interrupts on. One place you may want to turn them off is around updating the SS:SP values of the stack pointer to avoid a bug with some very ancient batches of 8088 processors from the early 1980s. If you are switching into protected mode then you will need to turn off interrupts while switching to protected mode and do so until you establish a protected mode interrupt descriptor table (IDT) to handle interrupts.

I have seen some bootloaders out there that do a CLI at the beginning and keep them off for no real reason.

Re: Clearing interruptions in a bootloader

Posted: Thu Nov 19, 2020 10:25 pm
by BenLunt
Be like the second timer of the old PIT and refresh my memory. Did the old 8088 have a different stack or did the author of that response actually get the wording wrong?
"When a word is added to the stack, the SP register is first incremented by 2..."
"A POP Instruction...then the SP register is decremented by 2".
I am guessing that they meant that the register is incremented in the direction away from the first of the stack. In reality, the incremented and decremented words should be swapped, yes?

That brings back a lot of memories though. December of 1987. I actually have a collection of some physical copies of that magazine from around that time.

Re: Clearing interruptions in a bootloader

Posted: Thu Nov 19, 2020 10:51 pm
by Octocontrabass
The author has the wording wrong, PUSH decreases the value of SP and POP increases it. That hasn't changed since the 8088.

What has changed is the order of operations. On an 8088, PUSH decrements SP, then writes the value to memory. On a modern x86 CPU, PUSH writes the value to memory first, then decrements SP. It's an important difference if you happen to use PUSH SP somewhere in your code! (It's also a quick way to detect if the CPU is at least a 286.)

Re: Clearing interruptions in a bootloader

Posted: Thu Nov 19, 2020 10:57 pm
by MichaelPetch
BenLunt wrote:Be like the second timer of the old PIT and refresh my memory. Did the old 8088 have a different stack or did the author of that response actually get the wording wrong?
"When a word is added to the stack, the SP register is first incremented by 2..."
"A POP Instruction...then the SP register is decremented by 2".
I am guessing that they meant that the register is incremented in the direction away from the first of the stack. In reality, the incremented and decremented words should be swapped, yes?
That would me an error in that publication, correct. The one place that things differed on the processors earlier than the 80286 was how PUSH SP operated. PUSH SP on >=80286 pushed the value of SP as it was before SP was decremented by 2 where as the processors < 80286 pushed the value of SP that it was after it was decremented by 2.

Edit: While I was typing this up Octo pretty much said the same thing in a post I only saw after submitting my answer.

Re: Clearing interruptions in a bootloader

Posted: Fri Nov 20, 2020 9:01 am
by BenLunt
Ya, I figured. It was more of a statement than a question. Nostalgia and curiosity begs that I look in my storage and find the exact copy of that publication.

Ben

Re: Clearing interruptions in a bootloader

Posted: Fri Nov 20, 2020 11:39 am
by nullplan
Scorpion197 wrote:When building a bootloader, we have to clear all the interruptions. Why do we have to do such a thing ?
You have to disable interrupts during a CPU mode switch, because there is no way to change CPU mode and load IDTR in a single instruction. Therefore there will be a time between setting CPU mode and setting the IDTR during which an incoming interrupt would be misinterpreted: Either you set the IDT first, then an interrupt during real mode would read the protected-mode IDT as a real-mode IVT, or you change mode first, then an interrupt during protected mode would read the real-mode IVT as an IDT. Neither way will work. So, in theory, you could prepare an IDT, change modes, load the IDTR, and interrupts would only be disabled for two instructions. Realistically, though, without the BIOS to support you, you will only be able to re-enable interrupts once you have enumerated all interrupt controllers and disabled all their interrupts, because otherwise you will get interrupts you don't know the meaning of. All of this requires far more code than you even need for a bootloader. So in short: Interrupts get disabled because it's easier.