Re: Why ISR contains no arguments and return type is void
From: Keith Williams (krw_at_att.bizzzz)
Date: 08/24/04
- Next message: Reg Edwards: "Re: ot BUSH BANNED MILITARY AND TANG OFFICERS FROM DISCUSSING HIS GUARD RECORD"
- Previous message: Keith Williams: "Re: OT: Wheeeeee! New PSpice Benchmarks"
- In reply to: Ben Bradley: "Re: Why ISR contains no arguments and return type is void"
- Next in thread: Active8: "Re: Why ISR contains no arguments and return type is void"
- Reply: Active8: "Re: Why ISR contains no arguments and return type is void"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 24 Aug 2004 13:35:10 -0400
In article <vqtmi095oa73ple1r0vet6036i2uli292n@4ax.com>,
ben_nospam_bradley@mindspring.com says...
> On Tue, 24 Aug 2004 12:13:01 -0400, Active8 <reply2group@ndbbm.net>
> wrote:
>
> >On Tue, 24 Aug 2004 20:13:50 +1000, Roger Lascelles wrote:
> >
> >> An ISR is called when a hardware event occurs and is not called by code, so
> >> parameters cannot be passed to it. In addition, when you write an ISR, you
> >> know what conditions caused the interrupt,
> >
> >Not always, you may have to check flags while in the ISR to
> >determine the event.
> >
> >> and therefore know what to do
> >> about it, without needing parameters to give additional information.
> >>
> >> An ISR returns nothing, because there is no calling code to read the
> >> returned values - on return, program execution returns to the original
> >> instruction stream.
> >>
> >> Roger
> >>
> >This is not entirely true, but the OP hasn't even bothered to
> >mention what friggin' uP he's using. In ix86 ass'y, there are BIOS
> >Ints.
>
> I've always cringed at the idea (in IBM PC's, which are admittedly
> 99.97% of the 80(x)86's) of a software "interrupt" or break
> instruction being called an interrupt. You know when it's going to
> happen and what it's going to do, just as you do in a subroutine call.
A subroutine call explicitly defines the address of the target
instruction. An x86 "soft interrupt" traps to an interrupt vector,
much like an x86 hardware interrupt. I suppose "trap" would be a
better word, but...
> Perhaps the worst part was that the word "interrupt" became equated
> with BIOS or DOS system call, and "real" interrupts such as the
> keyboard interrupt and 18.2(odd) ticks-per-second timer interrupt had
> to be called "hardware interrupts" to distinguish them from OS calls.
I never had any trouble keeping them straight. It's just semantics.
Every processor has a different "language".
> IIRC, the Mac used a similar instruction (one word, basically "go
> to vector x in the vector table") named trap in the 68000, and these
> OS calls were called 'trap' calls. At least that didn't cause the
> confusion over the name interrupt.
There are many word in this world that have several meanings, verse
visa. ;-) If you really want confusion try comparing cache
organizations (sectors/lines/ways/sets). Everyone uses the terms
differently.
-- Keith
- Next message: Reg Edwards: "Re: ot BUSH BANNED MILITARY AND TANG OFFICERS FROM DISCUSSING HIS GUARD RECORD"
- Previous message: Keith Williams: "Re: OT: Wheeeeee! New PSpice Benchmarks"
- In reply to: Ben Bradley: "Re: Why ISR contains no arguments and return type is void"
- Next in thread: Active8: "Re: Why ISR contains no arguments and return type is void"
- Reply: Active8: "Re: Why ISR contains no arguments and return type is void"
- Messages sorted by: [ date ] [ thread ]