Some odd result with 2 ISR.

[hgb]

I there, I have setup two interrupt handlers...

By the way, Im already in pmode and the selectors are for 16 bits...

Code: Select all

isr_00_wrapper:
   push ds
   push es
   pusha
   mov ax, 0x10
   mov ds, ax
   mov es, ax
   call isr_00
; ** I have added here for test of return a print "isr_00 has returned"
   popa
   pop es
   pop ds
   iret

isr_20_wrapper:
   push ds
   push es
   pusha
   mov ax, 0x10
   mov ds, ax
   mov es, ax
   call isr_20
   popa
   pop es
   pop ds
   iret

I "call" or request is "aparition" with

Code: Select all

   int 0x20
   xor bx, bx
   div bl

The point is that the two print is respective message msg0 (for isr_00) and msg20 for isr_20.

Now my question is, if I comment the lines abou the division by zero, the programm execution continue his flow and the termination message is printed.

But if I the divide exception (or interruption) cause that the control dosent flow, but I have tracked to the mark ** above int he code with a print of string that it return.


Also I have tryied copy completely the code of "isr_20_wrapper:" to "isr_00_wrapper:" without change nothing even the call to isr_20, and the hang continue there.



Hope I have explained my situation, any tought?, is that the correct behaviour?, I need cleear some flag or something for interrupt 0 ?


Thx, if you need more of my code say me...

[hgb]

Aparently I have watched or have handled for the moment how to go with this...

Doing some prints I have finded that the things is repeating itself again and again, that will be only if it was called again and again... Then I have decided to change the saved cs:ip +1 for the interrupt handler...

Code: Select all

   popa
   pop es
   pop ds
   mov bx, sp
   mov ax, [ss:bx]
   add ax, 1 ; here !!!
   mov [ss:bx], ax
   iret

The thing now continue and go on...

I have readed in http://www.clipx.net/ng/asm/ng74d8.php in the notes that "8088/8086" the saved CS:IP is the next instruction after the failed div... and for "80286 and 80386" point to the instruction that cause the fault... I supose this apply to computers of today???


mmm also I supose I must then make a type of little "decoder" of see if de division by zero was from a div, idiv and see the size of the operand??? for see if I will add 1, 2.. or perhaps more??? (I dont know much about opcodes....)

[Kemp]

Some return to the next line, some to the problem line, it depends which exception occured. I believe div by zero is meant to return to the problem line, which explains your problem. On a different note, the advice is to terminate a program that causes a div by zero as there are usually two scenarios:

a) It's a badly written or unstable program and so deserves to be killed
b) The next few lines of code rely on the division (which was accidently by zero) which will make it become unstable when the division fails to work as expected.

[hgb]

Then from that point of view, there is no necesity to write a little decoder??.. I see.

I was thinking in that, because in my case I was testing the esceptions and continue with the program flow was necesary for see the end message "hang here".

Actually I dont have task perhaps the one that can be called CPU thread or line thread but there is no necesity to terminate it .

I supose when I have process I can get wich one is terminate it, and instead to return to that process, simply continue with the next ready or some like that.

Thx for the help.

[Kemp]

Then from that point of view, there is no necesity to write a little decoder??.. I see.

If by decoder you mean the service routine then you'll still need it, otherwise you won't know the error occurred.

I was thinking in that, because in my case I was testing the esceptions and continue with the program flow was necesary for see the end message "hang here".

Actually I dont have task perhaps the one that can be called CPU thread or line thread but there is no necesity to terminate it .

Yeah, I was guessing that you were at the stage of just testing the service routines work rather than jumping in head first and getting the whole tasking model working and *then* working on the service routines (while probably possible, it would be hell to do).

I supose when I have process I can get wich one is terminate it, and instead to return to that process, simply continue with the next ready or some like that.

That's the basics of what I'll be doing with mine but don't take my advice as gospel, if you have a different way then go for it, it may work out much better

[hgb]

By decoder I mean some like

this is in 32 bits (olly..)

Code: Select all

F6F3          div bl
66:F7F3       div bx
F7F3          div ebx

From a listing in 16 bits

Code: Select all

F6F3                    div bl ; add 2 to the saved ip..
F6F3                    div bl
F7F3                    div bx
66F7F3                  div ebx ; add 3
F6367B00                div byte[123] ; add 4
F7367B00                div word[123]
66F7367B00              div dword[123] ;add 5
F737                    div word[bx] ; add 2
66F737                  div dword[bx] ; add 3
6667F733                div dword[ebx] ; add 4

I was thinking in check the value saved (when iret restore CS:IP), take the value like I have taked it before for add the 1.. by the way, now I see that I must add 2.. not one.. lol.

You see, that is to what I was refering like decoder, for know how many I will need to add to the CS:IP that have caused the fault.

[AR]

Divide by Zero is an "abort". The way OS' handle this is to send the program a signal to handle the problem (if it doesn't have a handler then it is just killed).

You should never need an instruction decoder for anything other than emulation (eg. V8086).

[hgb]

You mean raise a esception to the program, and if the programm have a zero division handler, then you dont terminate it, but if it does not, is terminated inmediately... .


Actuall Im "translating" the 17 pmtuts by Alexei, when I do the multitasking and such things, I will start to see how esception handling can be implemented .