OSDev.org

... if you're going to be sarcastic, please mark it as such.

Yes, x86 (and to a lesser extent ARM) are kinda crazy at the architecture level, but interrupts are not the example you should pick (interrupts are one of the best low-level features if you want any form of performance)

I do (however) kinda agree that we need to rethink platforms to get better multi-core performance, and that's the direction systems research should be looking (that and working on new languages that make multi-threading easier to get correct)

Geri wrote:why the hell we even have interrupts?

Go write an operating system that can saturate both the PCIe and SATA3 buses while doing nothing but polling and still accept and process user input and draw 3D graphics at a framerate meeting or exceeding your monitor's refresh rate.

I will eat a leather hat if you can.

Hi,

thepowersgang wrote:... if you're going to be sarcastic, please mark it as such.

Yes, x86 (and to a lesser extent ARM) are kinda crazy at the architecture level, but interrupts are not the example you should pick (interrupts are one of the best low-level features if you want any form of performance)

I do (however) kinda agree that we need to rethink platforms to get better multi-core performance, and that's the direction systems research should be looking (that and working on new languages that make multi-threading easier to get correct)

I'm not too sure what Geri was thinking; however...

It actually would be nice to get rid of IRQs and replace them with "hardware messages"; where a hardware message interrupts the currently running code (just like an IRQ would have), but consists of a "sender ID" (to identify the device that sent the IRQ) and some sort of device specific "status dword" (to identify the reason why the device is requesting attention - so the driver can figure out what it needs to do before/without touching the device's registers).


Cheers,

Brendan