In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
Mark McIntyre <ma**********@spamcop.net> writes: On 23 Aug 2004 09:26:57 -0700, in comp.lang.c , sw************@yahoo.co.in
(Sweety) wrote: >hello,
> Is there any code using interrupts .
You can't do this in Standard C. Didn't someone already tell you that?
Please go to a group specialising in your hardware, and ask there.
Now that I think about it, this might refer to the facilities in
<signal.h>. (Is there a distinction between "signals" and
"interrupts"?)
Yup, a fundamental one: an signal handler is an ordinary C function,
treated by the compiler like any other function (the compiler has no
idea it is compiling a signal handler) while an interrupt handler must
save *all* the CPU state it is disturbing upon entry and restore it
before returning. On most CPUs, it must also reenable the interrupt
that invoked it, usually using a different kind of return instruction
("return from interrupt" instead of "return from subroutine").
The declaration of a signal handler is:
void handler(int);
while the typical declaration of an interrupt handler is something like
void interrupt inthandler(void);
where the "interrupt" extension tells the compiler to add all the code
for performing the actions described above.
As interrupt handlers belong to the OS kernel, the need for such an
extension is limited to freestanding implementations and to very
primitive hosted platforms, like MSDOS, where there is no difference
between user code and OS code.
Because the serial port drivers of MSDOS are not interrupt driven,
any user program that needs *reliable* serial communication MUST
provide its own interrupt handler(s) for the serial port(s) it uses.
Easily done in C, because most MSDOS compilers provide the "interrupt"
extension described above along with library support for accessing the
I/O ports.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email:
Da*****@ifh.de 
