interrupt confusion! please clarify

[elias]

i thought interrupts were disabled in pmode. if this is true, then how do people access disks since they are disabled!!!? and also, how is the OS notyfied when a key has been pressed? dosnt the keyboard do this through interrupts? the only solution i can see is that they really arnt disabled, but all documentation says they are. can someone explain? i know im not the only one with this misunderstanding too.

[_PlayOS]

Hi,

well, interrupts must be disabled before a switch to pmode, once the switch has been made and a valid IDT setup you can re-enable ints, however disk access and keyboard must be programmed yourself directly using the hardware because ints as you know them in real mode are gone, unless you preserve the IVT and use v86 mode, you can use ints for these but I would suggest that you just write a driver that is part of your kernel for these two devices as they are both pretty much definately going to be in all systems.

hope this helps.

[Tom]

you can get disk acsess & keyboard stuff through in's and out's

[Whatever5k]

you can get disk acsess & keyboard stuff through in's and out's

Right, but this is not a good solution, because it means polling the hardware ports...

Generally, if the BIOS loads a kernel, interrupts are enabled, and we can use BIOS interrupts. But if we want to switch to Protected Mode, we have to set up a valid IDT, with valid descriptors pointing to a interrupt handler for each interrupt. So we turn off interrupts and enable them if we have a valid IDT.
So, if we press a key, we get an IRQ1 (which is mapped to interrupt 0x21, for example), and the IDT contains the descriptor which also contains the address of the interrupt handler. This interrupt handler then reads from the keyboard port...

[elias]

so you guys are basically saying that you can have interrupts in pmode? but you have to write all the handlers yourself. and i have to write my own drivers for disk access, but for things that must notify the OS when they happen, like a keyboard press, what do I do then? map it to the IRQs? im so confused

[Tom]

[attachment deleted by admin]

[Schol-R-LEA]

you just do this for keys...you don't need anything special... just functions.

While this approach - called polling - will work, it presents serious problems in a multitasking system. First off, you are actively waiting for the event to occur; this is called 'busy waiting' and it wastes CPU time with continuous loops that do nothing. If you use an interrupt handler for the incoming events (keypresses and keyreleases, in this case), then you can simply have your process sleep until woken by the interrupt handler, freeing the CPU for other processes.

Second, if the loop doesn't relinquish the CPU - either cooperatively, by calling the scheduler directly, or preemptively, when the scheduler timer switches processes - then the whole system is locked up waiting on this one event; if the key never gets pressed, the system comes to a halt. On the other hand, if it does relinquish the CPU, it risks the possibility that, by the time the process schedules to run again, it will have missed one or more events in the interval since it last ran.

Unless you are building a system that enforces cooperative multitasking at the compiler level (e.g., Oberon), and have all the events polled in turn by a master event loop, polling is a bad way to handle hardware events. Since it is absolutely necessary to write *some* sort of IDT (even if the handlers simply ignore the interrupt) in order to handle CPU exceptions, it is best just to write some kind of stub handler which then calls the actual driver code. Better still would be an interrupt handler which queues the event information and sends a message or signal to the driver; this separates the interrupt handlers from the drivers themselves, and lets the system return from the interrupt faster (though it doesn't necessarily handle the event faster overall). This last is the classic approach taken by microkernel systems, and while it does lose some efficiency, it gains a lot of flexibility.

[elias]

so does pmode allow interrupts or not? how come everyone says it dosnt? so if im going to write a multitasking system in pmode, i have to write my won IVT? is this what everyones been trying to tell me? and if im in pmode, can i used the assenmbly opcode INT? to actaully call an interrupt?

[Pype.Clicker]

short answer: YES, interrupt works. you can call them, have hardware IRQ, etc. BUT the BIOS and DOS services that usually were called by interrupts become useless because they're in 16bits and you're in 32bits mode ...

so

Code: Select all

mov ax,0x0013
int 0x10

is still valid but you can't set up 320x200x256 that way in pmode.
hope it breaks the confusion ...

[Schol-R-LEA]

The problem seems to lie in a confusion between interrupts, as a hardware system, and the practice of using software-generated interrupts (INT instructions) to access BIOS and OS functions.

An interrupt is simply a hardware event that causes the CPU to suspend and save the current thread of execution, and run a special routine called an interrupt handler. When an interrupt occurs, it identifies itself by a number, which the CPU uses to look up the address of the handler, either in the Interrupt Vector Table (in real mode) or the current Interrupt Descriptor Table (in protected mode).

The primary purpose interrupts is to respond to external events (hardware interrupts). Which interrupt is generated by which event is actually determined by the settings on a secondary chip, the Programmable Interrupt Controller (PIC), which receives the actual Interrupt Requests (IRQs) from the peripherals, and forwards them to the CPU with an appropriate interrupt vector. It is the duty of the OS designer to ensure that the interrupt handlers match the appropriate interrupt vector, of course.

In addition to this, the CPU allows you to signal an interrupt in software, using the INT instruction. While the main reason this was added to the CPU was for debugging purposes (so you could test the interrupt handlers), it also is used to vector BIOS and operating system calls, especially in real mode. This is done primarily because the position of the function may change in different versions of the software; the interrupt number acts as a handle, allowing the system to redirect the call to the appropriate location.

During the pre-bootup stage, the BIOS initializes part of the IVT to point to some basic interrupt handlers, including the BIOS call vectors (0x10, 0x13, 0x15, etc.). MS-DOS, and most other real-mode OSes, modify the IVT further, adding vectors to their own device drivers and system calls. However, these routines are all 16-bit real-mode code, and will not work if the system is switched into 32-bit protected mode (the 16-bit protected mode from the '286 is... confusing... on this point, and not worth bothering with). Furthermore, since interrupt vectors are now defined in the IDT, not the IVT, the interrupt vectors themselves are likely to be different, unless the OS programmer sets them to the same values - which is pointless, as the BIOS code no longer works, anyway. Thus, while the interrupt mechanism works, it cannont be used to call the BIOS functions.

Note that in many newer systems, there are a handful of advanced BIOS routines that are 32-bit p-mode code, but only a few machines have them, and they generally only provide services which require specific knowledge of the hardware - for example, the memory size determination function, the VESA VBE v. 3.0 video calls, or the power management BIOS. Since these are not universally available, you should not rely on them too heavily. For more on the 32-bit BIOS routines, see Ralf Brown's Interrupt List.

While a few p-mode OSes have some sort of interrupt-based system calls (e.g., the infamous INT 80 calls in Linux, which are generally considered 'undocumented'), most use call gates for system calls instead.

[elias]

thanx, that clarified a lot. but let me jsut make sure i understand. in pmode, you can have interrupts occur, but programs cant generate them, with an INT command. but once the CPU gets the intteurpt from the IRQ, it goes to the IDT, and gets that bit of code, right? but since int 0x10 dosnt work, how do i do stuff wiht the video card? i know linux does, but how? and where is the IDT stored? do i have to write every interrupt handler i want to use myslef? even the VGA interrupt?

[Tom]

for using int 0x10 ( the Video BIOS ) you need "v86 Mode" - complicated.

[elias]

does linux use V86 mode?

[Tom]

yes.

[elias]

wait, so if i am to have a multitaksing system, shoudl i use V86 mode? whats the point of protected mode if interrupts are disabled? they are esential to the PC, so why would i use pmode?