Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
How to make sure interrupt is NOT generated between code snippets ?
60 views
Skip to first unread message
liaoo
Apr 8, 2013, 10:41:01 PM4/8/13
to
I have one question about the timing of interrupt generation between code snippets...Let me briefly describe as follows:
@ "example" code
1. ...
2. assign value to global variable // 0/1 means invalid/valid
3. set H/W register via memory-mapped IO method // 0 means completed
@ "example" ISR code
a. ...
b. if(global value is valid && H/W register is "0") then count++;
* One thing to note: After H/W register is set, its value will be 0 when "completion" !
My question is: if the interrupt is generated between 2 and 3, then count will be increased by one because step 3 is not done yet(value is 0)... And if exchange 2 and 3, then it is possible count will NOT be increased by 1 because even HW register is 0(after some time, completed) global variable is 0 !
My first idea : is it possible 2 and 3 can be "tied together" in some way and interrupt is not allowed to be generated until 3 is done ?
* I use watcom c and test in DOS...
@ "example" code
1. ...
2. assign value to global variable // 0/1 means invalid/valid
3. set H/W register via memory-mapped IO method // 0 means completed
@ "example" ISR code
a. ...
b. if(global value is valid && H/W register is "0") then count++;
* One thing to note: After H/W register is set, its value will be 0 when "completion" !
My question is: if the interrupt is generated between 2 and 3, then count will be increased by one because step 3 is not done yet(value is 0)... And if exchange 2 and 3, then it is possible count will NOT be increased by 1 because even HW register is 0(after some time, completed) global variable is 0 !
My first idea : is it possible 2 and 3 can be "tied together" in some way and interrupt is not allowed to be generated until 3 is done ?
* I use watcom c and test in DOS...
Ross Ridge
Apr 8, 2013, 11:04:46 PM4/8/13
to
liaoo <jimmy...@gmail.com> wrote:
>My first idea : is it possible 2 and 3 can be "tied together" in some way a=
prevent all hardware interrupts until you set it again.
>* I use watcom c and test in DOS...
I believe Watcom uses the functions _disable() and _enable() to disable
and enable interrupts respectively.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
>My first idea : is it possible 2 and 3 can be "tied together" in some way a=
>nd interrupt is not allowed to be generated until 3 is done ?
You can clear the interrupt flag in the status register and this will
prevent all hardware interrupts until you set it again.
>* I use watcom c and test in DOS...
and enable interrupts respectively.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
liaoo
Apr 9, 2013, 2:13:54 AM4/9/13
to
> You can clear the interrupt flag in the status register and this will
>
> prevent all hardware interrupts until you set it again.
>
> prevent all hardware interrupts until you set it again.
> I believe Watcom uses the functions _disable() and _enable() to disable
>
> and enable interrupts respectively.
Thanks ! I used inline assembly "cli and sti" to disable/enable interrupts for this purpose and it was OK.
>
> and enable interrupts respectively.
Finally I just mask the interrupt device used(instead of masking "all" maskable interrupts) to make other interrupts work well by configuring 8259s...
liaoo
May 13, 2014, 10:45:51 AM5/13/14
to
Hi all,
Recently I found the same error occurs if MSI mode is used.
That is, MSI interrupt can NOT be blocked via _disable() in DOS. And it may assert between step 2 and 3 in above code, thus causes code in interrupt service routine misjudge...
My question is: is there any way to block Message Signaled Interrupt "temporarily" or "tie" (step 2 and 3) together to prevent it from being interrupted by MSI ?
Thanks !
Recently I found the same error occurs if MSI mode is used.
That is, MSI interrupt can NOT be blocked via _disable() in DOS. And it may assert between step 2 and 3 in above code, thus causes code in interrupt service routine misjudge...
My question is: is there any way to block Message Signaled Interrupt "temporarily" or "tie" (step 2 and 3) together to prevent it from being interrupted by MSI ?
Thanks !
Ross Ridge
May 13, 2014, 2:52:09 PM5/13/14
to
maskable interrupts regardless of how they're delivered or whether
though the legacy PIC, I/O APIC or Local APIC, whether through PCI MSI
signalling or the normal PCI INT[A-D]# lines. The only exception are
the non-maskable interrupts like NMI and SMI but by their nature you
shouldn't need to mask them.
So the way to temporarily block an MSI is to use the sti instruction.
If that doesn't seem to be working then your problem must be somewhere
else.
Also as I undertand it, PCI MSI interrupts won't work under MS-DOS.
They require enabling the processor's Local APIC which makes interrupt
processing incompatible with software that assumes the legacy 8259 PIC
is being used. In other words incompatible with any interrupt routines
used under MS-DOS. You'd have to install your own interrupt handlers
for all external interrupts, including all those handled by the BIOS,
MS-DOS itself and any third-party software or drivers. You effectively
wouldn't be running MS-DOS anymore.
NimbUs
May 13, 2014, 5:58:25 PM5/13/14
to
Ross Ridge wrote @ news:lktpkp$i78$1...@rumours.uwaterloo.ca:
> The sti instruction generated by the _disable() function
disables all
> maskable interrupts regardless of how they're delivered
Did you mean the _cli_ instruction rather ?
or whether
> though the legacy PIC, I/O APIC or Local APIC, whether
through PCI MSI
> signalling or the normal PCI INT[A-D]# lines. The only
exception are
> the non-maskable interrupts like NMI and SMI but by their
nature you
> shouldn't need to mask them.
>
> So the way to temporarily block an MSI is to use the sti
instruction.
Again !
You must be tired... Get some rest is my friendly advice :=)
--
NimbUs
> The sti instruction generated by the _disable() function
disables all
> maskable interrupts regardless of how they're delivered
or whether
> though the legacy PIC, I/O APIC or Local APIC, whether
through PCI MSI
> signalling or the normal PCI INT[A-D]# lines. The only
exception are
> the non-maskable interrupts like NMI and SMI but by their
nature you
> shouldn't need to mask them.
>
> So the way to temporarily block an MSI is to use the sti
instruction.
You must be tired... Get some rest is my friendly advice :=)
--
NimbUs
liaoo
May 14, 2014, 3:44:08 AM5/14/14
to
Ross Ridge於 2014年5月14日星期三UTC+8上午2時52分09秒寫道：
After trying sti/cli in in-line assembly and _enable()/_disable() I found my test program works well and I can infer that either way protects the code from being interrupted(Maybe I really have to get some rest...)
>
> Also as I undertand it, PCI MSI interrupts won't work under MS-DOS.
>
> They require enabling the processor's Local APIC which makes interrupt
>
> processing incompatible with software that assumes the legacy 8259 PIC
>
> is being used. In other words incompatible with any interrupt routines
>
> used under MS-DOS. You'd have to install your own interrupt handlers
>
> for all external interrupts, including all those handled by the BIOS,
>
> MS-DOS itself and any third-party software or drivers. You effectively
>
> wouldn't be running MS-DOS anymore.
>
>
>
> Ross Ridge
MSI can work in MS-DOS according to my experience...
My test program is executed in MS-DOS(not the command prompt in OS). It supports both Pin-based and MSI mode. As you said first s/w should check if local APIC is enabled or not(usually enabled as default), then s/w should install the interrupt service routine and need to issue EOI(memory write to specific address) at the end of ISR.
BTW, the interrupt vector for MSI I used is 0x70. When MSI generated, we will see memory write occurs(Address:0xFEE00000, Data:0000C070)
I just install the interrupt handler of my own and leave others unchanged. After program exit, MS-DOS is alive and I can edit file or ....
F.Y.I
Ross Ridge於 2014年5月14日星期三UTC+8上午2時52分09秒寫道：
> liaoo <jimmy...@gmail.com> wrote:
>
> >Recently I found the same error occurs if MSI mode is used.
>
> >
>
> >That is, MSI interrupt can NOT be blocked via _disable() in DOS. And
>
> >it may assert between step 2 and 3 in above code, thus causes code in
>
> >interrupt service routine misjudge...
>
> >
>
> >My question is: is there any way to block Message Signaled Interrupt
>
> >"temporarily" or "tie" (step 2 and 3) together to prevent it from being
>
> >interrupted by MSI ?
>
>
>
> The sti instruction generated by the _disable() function disables all
>
> maskable interrupts regardless of how they're delivered or whether
>
> though the legacy PIC, I/O APIC or Local APIC, whether through PCI MSI
>
> signalling or the normal PCI INT[A-D]# lines. The only exception are
>
> the non-maskable interrupts like NMI and SMI but by their nature you
>
> shouldn't need to mask them.
>
>
>
> So the way to temporarily block an MSI is to use the sti instruction.
>
> If that doesn't seem to be working then your problem must be somewhere
>
> else.
>
YES, you are right !
>
> >Recently I found the same error occurs if MSI mode is used.
>
> >
>
> >That is, MSI interrupt can NOT be blocked via _disable() in DOS. And
>
> >it may assert between step 2 and 3 in above code, thus causes code in
>
> >interrupt service routine misjudge...
>
> >
>
> >My question is: is there any way to block Message Signaled Interrupt
>
> >"temporarily" or "tie" (step 2 and 3) together to prevent it from being
>
> >interrupted by MSI ?
>
>
>
> The sti instruction generated by the _disable() function disables all
>
> maskable interrupts regardless of how they're delivered or whether
>
> though the legacy PIC, I/O APIC or Local APIC, whether through PCI MSI
>
> signalling or the normal PCI INT[A-D]# lines. The only exception are
>
> the non-maskable interrupts like NMI and SMI but by their nature you
>
> shouldn't need to mask them.
>
>
>
> So the way to temporarily block an MSI is to use the sti instruction.
>
> If that doesn't seem to be working then your problem must be somewhere
>
> else.
>
After trying sti/cli in in-line assembly and _enable()/_disable() I found my test program works well and I can infer that either way protects the code from being interrupted(Maybe I really have to get some rest...)
>
> Also as I undertand it, PCI MSI interrupts won't work under MS-DOS.
>
> They require enabling the processor's Local APIC which makes interrupt
>
> processing incompatible with software that assumes the legacy 8259 PIC
>
> is being used. In other words incompatible with any interrupt routines
>
> used under MS-DOS. You'd have to install your own interrupt handlers
>
> for all external interrupts, including all those handled by the BIOS,
>
> MS-DOS itself and any third-party software or drivers. You effectively
>
> wouldn't be running MS-DOS anymore.
>
>
>
> Ross Ridge
My test program is executed in MS-DOS(not the command prompt in OS). It supports both Pin-based and MSI mode. As you said first s/w should check if local APIC is enabled or not(usually enabled as default), then s/w should install the interrupt service routine and need to issue EOI(memory write to specific address) at the end of ISR.
BTW, the interrupt vector for MSI I used is 0x70. When MSI generated, we will see memory write occurs(Address:0xFEE00000, Data:0000C070)
I just install the interrupt handler of my own and leave others unchanged. After program exit, MS-DOS is alive and I can edit file or ....
F.Y.I
>
>
> --
>
> l/ // Ross Ridge -- The Great HTMU
>
> [oo][oo] rri...@csclub.uwaterloo.ca
>
> -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
>
> db //
Ross Ridge於 2014年5月14日星期三UTC+8上午2時52分09秒寫道：
>
> --
>
> l/ // Ross Ridge -- The Great HTMU
>
> [oo][oo] rri...@csclub.uwaterloo.ca
>
> -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
>
> db //
Ross Ridge
May 16, 2014, 9:01:26 PM5/16/14
to
Ross Ridge wrote @ news:lktpkp$i78$1...@rumours.uwaterloo.ca:
> The sti instruction generated by the _disable() function disables all
> maskable interrupts regardless of how they're delivered
> The sti instruction generated by the _disable() function disables all
> maskable interrupts regardless of how they're delivered
NimbUs <nim...@XXX.invalid> wrote:
>Did you mean the _cli_ instruction rather ?
Yes, I got the two instructions mixed up. On Intel processors cli disables
>Did you mean the _cli_ instruction rather ?
all maskable interrupts and sti renables them. That's what I get for
answering a 6502 related question in another newsgroup.
Rod Pemberton
May 17, 2014, 4:04:20 PM5/17/14
to
On Fri, 16 May 2014 21:01:26 -0400, Ross Ridge
<rri...@csclub.uwaterloo.ca> wrote:
I was going to ask if you ever programmed the 6502, but decided it
wasn't of any importance. I learned 6502 first, a few decades before
learning x86, and I do that with x86 too.
Rod Pemberton
<rri...@csclub.uwaterloo.ca> wrote:
> NimbUs <nim...@XXX.invalid> wrote:
>> Ross Ridge wrote @ news:lktpkp$i78$1...@rumours.uwaterloo.ca:
>>> The sti instruction generated by the _disable() function disables
>>> all maskable interrupts regardless of how they're delivered
>>>
>> Ross Ridge wrote @ news:lktpkp$i78$1...@rumours.uwaterloo.ca:
>>> The sti instruction generated by the _disable() function disables
>>> all maskable interrupts regardless of how they're delivered
>>>
>> Did you mean the _cli_ instruction rather ?
>
> Yes, I got the two instructions mixed up. On Intel processors cli
> disables all maskable interrupts and sti renables them. That's
> what I get for answering a 6502 related question in another newsgroup.
>
Ha!
>
> Yes, I got the two instructions mixed up. On Intel processors cli
> disables all maskable interrupts and sti renables them. That's
> what I get for answering a 6502 related question in another newsgroup.
>
I was going to ask if you ever programmed the 6502, but decided it
wasn't of any importance. I learned 6502 first, a few decades before
learning x86, and I do that with x86 too.
Rod Pemberton
James Harris
May 18, 2014, 3:51:27 AM5/18/14
to
"Rod Pemberton" <dont_us...@xnothavet.cqm> wrote in message
news:op.xf0spid16zenlw@localhost...
Ditto. And doesn't the 6502 also handle subtraction borrow the opposite way
from x86?
I have an idea Arm's borrow works the same way as the 6502 so Chuck must
have been doing something right.
James
news:op.xf0spid16zenlw@localhost...
from x86?
I have an idea Arm's borrow works the same way as the 6502 so Chuck must
have been doing something right.
James
0 new messages