Get vector number in IRQ handler

[rdos]

Rdos just defined adding or removing code as being no change.

GTFO.

Could you please learn to read.

When adding a new handler, which is when I add more code, I only append the new handler at the end, and setup a new code selector. This also does not change the code. The code (as in instructions) is not modified in any way.

[Combuster]

In a flat memory model, there is no position independence

Lies. GTFO.

[Combuster]

which is when I add more code

So your argument is invalid. GTFO.
So YOU can't read. GTFO.

I can keep doing this for an eternity.

[rdos]

This all seems a bit hackish - why not just use a macro to define your interrupt stubs (as suggested above?).

This is a speed optimization. You create the content of the stub depending on what it would do. Instead of letting the stub push the interrupt vector (or possibly global interrupt number if you have dynamic IDT setup), you let the stub directly call the handler. It works best in a segmented memory model as it reduces segment register loads, but it might very well work better in a flat memory model as well, but then there will be different tuning aspects. One thing that must be solved is position independence. You could patch the code itself to fix that. For instance:

Code: Select all

    mov esi,OFFSET param_header   ; patch this with the linear address of the param block
    push [esi].param1
    call [esi].routine

[rdos]

which is when I add more code

So your argument is invalid. GTFO.
So YOU can't read. GTFO.

I can keep doing this for an eternity.

I won't. This is my final answer to you in this thread.

In a flat memory model, there is no position independence

Lies. GTFO.

The position independency is solved in the loader, but since we create content dynamically here, it won't work.

End-and-out.

[Combuster]

Code: Select all

pusha
call label
label:
pop eax
mov ebx, commonStub
push [eax + data-label]
jmp ebx
data: DD 0

Here's your proof, liar.