OSDev.org

i have few problems with it.

Should i use CLI before signaling EOI to pic? if pic will send me an interrupt before i iret, wstack will nest and possibly overflow can occur it pic will flood me.


Ive tested it, and either pic doesnt want to send me new interrupt before i iret, or cpu is preventing its execution. I do not know.

what should i do?
ive seen code with cli before eoi. should i disable interrupts before eoi or not? will iret delay incomming interrupt processing or not?

Yes, you should have interrupts disabled before sending an EOI to the interrupt controller. You will need to find out for yourself if you need CLI to do it or not - after all you should know the details of your interrupt handling system.

i dont know who write manual.
intel manual does not even have a phrase 'ivt' 'interrupt vector table' or 'vector table' describing real mode interrupts.

How the f&^% im supposed to know it? Should i bruteforce my cpu agnist all possibles scenarios?

I know that TF is cleared when cpu enters interrupt. IF as well.
So IVT might be treated as interrupt gates. Is it true? Is ivt entry = interrupt gate?

When i set IF, im getting more irqs, meaning cli before eoi is retarded as the author of code i found. Unless there is an exception from this rule.

If they continue support of legacy stuff why wont they do it with manuals? Or maybe its me who cant find the right manual (having all of them on disk...). If so, please tell me where will i find real mode interrupt handling.

a5498828 wrote:i dont know who write manual.
intel manual does not even have a phrase 'ivt' 'interrupt vector table' or 'vector table' describing real mode interrupts.

How the f&^% im supposed to know it? Should i bruteforce my cpu agnist all possibles scenarios?

I know that TF is cleared when cpu enters interrupt. IF as well.
So IVT might be treated as interrupt gates. Is it true? Is ivt entry = interrupt gate?

When i set IF, im getting more irqs, meaning cli before eoi is retarded as the author of code i found. Unless there is an exception from this rule.

If they continue support of legacy stuff why wont they do it with manuals? Or maybe its me who cant find the right manual (having all of them on disk...). If so, please tell me where will i find real mode interrupt handling.

I think IVT is setup by BIOS. Hence, I suggest looking at the BIOS specifications.

a5498828 wrote:i dont know who write manual.
intel manual does not even have a phrase 'ivt' 'interrupt vector table' or 'vector table' describing real mode interrupts.

How the f&^% im supposed to know it? Should i bruteforce my cpu agnist all possibles scenarios?

Quoting from the TOC of Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3a: System Programming Guide:

CHAPTER 6
INTERRUPT AND EXCEPTION HANDLING
6.1 INTERRUPT AND EXCEPTION OVERVIEW
6.2 EXCEPTION AND INTERRUPT VECTORS
6.3 SOURCES OF INTERRUPTS
6.4 SOURCES OF EXCEPTIONS
6.5 EXCEPTION CLASSIFICATIONS
6.6 PROGRAM OR TASK RESTART
6.7 NONMASKABLE INTERRUPT (NMI)
6.8 ENABLING AND DISABLING INTERRUPTS
6.9 PRIORITY AMONG SIMULTANEOUS EXCEPTIONS AND INTERRUPTS
6.10 INTERRUPT DESCRIPTOR TABLE (IDT)
6.11 IDT DESCRIPTORS
6.12 EXCEPTION AND INTERRUPT HANDLING
6.13 ERROR CODE
6.14 EXCEPTION AND INTERRUPT HANDLING IN 64-BIT MODE
6.15 EXCEPTION AND INTERRUPT REFERENCE

Looks pretty complete to me.

Yeesh, calm down a5498828. The IVT is just an array of segment:offset pointers to their respective ISRs inside of the BIOS ROM software.

You should know it by reading the correct specs. But do not confuse IVT with IDT; the IVT is used in real mode, the IDT in protected mode. I can almost guarantee you will see both described in the Intel manuals.

intel manual does not even have a phrase 'ivt' 'interrupt vector table' or 'vector table' describing real mode interrupts.

Page 506 in my (slightly dated) version. Impossible to miss in the AMD manuals (idiots excluded). Better excuse wanted.

ok amd has it covered.

Looks pretty complete to me.

not to me, missing IVT. ctrl+f, ivt - no results

Is this the same smart-@$$ who thinks he can outperform an FPU on floating point arithmetic?

If you use an interrupt gate, the processor will clear the IF after pushing eflags so you don't have to do it yourself. In a trap gate, interrupts are not disabled however. Do you have a REALLY old version of the manuals or something?

Tosi wrote:If you use an interrupt gate, the processor will clear the IF after pushing eflags so you don't have to do it yourself. In a trap gate, interrupts are not disabled however. Do you have a REALLY old version of the manuals or something?

This topic is about real mode. Actually was because problem is solved, i dont know why its open yet. Wonder why cant i delete it or close to prevent unnecessary insults.

a5498828 wrote:...unnecessary insults...

No such thing here. Just unsuccessful insults (as in, you are still convinced that you are right and the world is wrong).

a5498828 wrote:

Solar wrote:Looks pretty complete to me.

not to me, missing IVT. ctrl+f, ivt - no results

And obviously you did not bother to think a second about what "IVT" stands for and trying your leet CTRL-F skills on "interrupt vector table", which would have given you numerous hits all over volume 3 of the manuals, including this tidbit here:

Intel Manual Volume 3A wrote:9.7.1 Real-Address Mode IDT
In real-address mode, the only system data structure that must be loaded into
memory is the IDT (also called the “interrupt vector table”).

I.e., my initial reference to chapter 6 and its documentation of the IDT was absolutely correct, and you, dear Sir, have been pawned by someone who has read the Intel Manuals but once, almost ten years ago, and never written any IVT / IDT handling code himself. Congrats.

PS: Oh, and if your problem was solved, it's basic netiquette to post how it was solved, so that others coming later would also benefit from your insight.

I'm still not getting what the actual problem was.