ia 32 has something called APIC since the P5 (or PPro?).

i didnt really looked deep into it, but i think it allows "cleaner" interrupt/exception handling.
and i think windows uses it (go in the device manager)

btw win already has its own HW-independant exception codes and so on i think (not related to intel)
Posted on 2004-06-16 16:07:15 by HeLLoWorld
Hello HelloWorld,


As far as I know the APIC is used in multiprocessor systems. That is several P6 processors have APIC controller in order to be placed in multiprocesor configuration. I think it is not related with the base address of the IRQs.

In the device manager only the IRQs are shown not the interrupt number in the interrupt table. That's why I'm curious, how does the Interrupt table look like in Windows? Maybe from compatibility issues the "old" standard is preserved that IRQ0 is interrupt 08h, IRQ1 is 09h, etc. But Interrupt 08h is also defined by Intel as Double Fault, and Interrupt 0ah as Invalid TSS, Interrupt 0bh as Segment not present, etc.
So if these vectors are overlapped than the operating system should test if an IRQ was happened or an software interrupt. And this is a very unefficient mode of handling.
I think it is much simpler to separate the intel reserved interrupts from the IRQs.
I think the Intel reserved Interrupts, the IRQs and the Operating system interrupts should be on different vectors, not interfering with each other.
Posted on 2004-06-16 16:35:57 by bszente
i dont see why they would still use the same for exceptions and irqs.
once you re in prot mode theres no reason...
Posted on 2004-06-16 16:39:27 by HeLLoWorld
That's the point, I don't know what is in behind. But Microsoft is not famous in optimization. And probable from compatibility issues, as I said (Win9x and WinNT4 etc) they keep the "standard".

Let me say another example. Why the sectors on the HDD contain only 512 bytes? I dont't see the reason. The 2k or 4k size sectors would be much more faster better, etc. And also it is VERY possible to format bigger sectors even on floppy disks. And amaizingly the waste of intersector zones would be smaller. But from COMPATIBILTY reasons we still use 512 byte sectors, and mess up with clusters and other stuffs. It would be perfect to use 4k sectors without clusters. In fact NTFS uses clusters of 4k (by default), so it would be good to use 4k sectors. And not to mention that also memory pages are 4k.

See? Not the logic decides in every case. That's why I'm saying that I'm not sure if Windows separates the 3 vectors.
Posted on 2004-06-16 16:47:57 by bszente
PIT is reprogrammed, even for win9x - otherwise there's no way whatsoever you could get the kind of task switching windows offers. Afaik, NT uses dynamic programming of the PIT.

APIC can be used on UP (uni/single-processor) systems as well, most modern systems support it. It has both better IRQ handling, but also some timer stuff afaik.

I'm pretty sure windows remaps IRQs to above the intel-reserved range - anything else would be outright stupid, and it's easy to do anyway.

NT has _very_ efficient interrupt handling by the way... almost everything is deferred to be handled later, so as little time as possible is spent in the IRQ handler.


That's the point, I don't know what is in behind. But Microsoft is not famous in optimization.

Compare linux to NT, then repeat that statement :rolleyes:

As for the sector-stuff for IDE drives... *shrug*. Harddrives probably don't use that internally anyway, so it's just a legacy interface. Dunno if it matters much - apart from of course limiting us currently to 512*2^48 byte harddrives (I believe current LBA adressing is 48bit max?).
Posted on 2004-06-17 04:52:09 by f0dder

PIT is reprogrammed, even for win9x
I'm pretty sure windows remaps IRQs to above the intel-reserved range

I see... :confused: so they did solve this problem. The problem is that I didn't found any documentation regarding this, but I think it would be interesting to know what happens in reality in Windows' background.

As for the sector-stuff for IDE drives... *shrug*. Harddrives probably don't use that internally anyway, so it's just a legacy interface. Dunno if it matters much

I think the sectors really have 512 bytes internally. You can even do sector renumbering (in the case of IDE drives, SCSI does not support sector renumbering) for quicker acces. Consecutive sector numbering is not a good approach, and usually there are numebered this way. And let's be serious... wouldn't be better/easyer to handle direcly 4kB sectors? Otherwise the whole clustering would be a nonsense, if the small sectors are better.
The 512 byte standard is a bad accustomed standard, and you cannot escape from it.

It somehow similar to x86 architecture: we still have the basic real mode compatibility. I saw some threads in this forum complaining about this problem: why should that 25 years old standard be incorporated in modern processors? To decrease efficiency and to comlicate our lifes.

But who knows? Maybe I'm wrong, and there are real needs for these "standards".
Posted on 2004-06-22 03:42:52 by bszente