On 2006-11-29, Paul Keinanen <keinanen@sci.fi> wrote:> On Tue, 28 Nov 2006 19:37:46 GMT, "Wilco Dijkstra" ><Wilco_dot_Dijkstra@ntlworld.com> wrote: > >>Well I can see some good uses for interrupts with arguments, >>making interrupt routines even easier to write in C. I'm sure >>someone has patented the idea already as it is quite obvious... > > The only use I could think of is that you have multiple interrupt > sources on the same interrupt vector, thus the hardware delivered > argument would identify which interrupt source activated the ISR.Another use would be to provide the pointer to the instruction that caused the interrupt in the case of things like a seg fault, SWI, or undefined instruction. That makes single-stepping, breakpoints, and simulating unsupported instructions easier. On many CPUs it would also be handy if ISRs had a return values that defined the status reguster value to be used after return from interrupt. That would make it simpler to do things like wake the CPU up from sleep mode without having to jigger the status value that's on the stack. -- Grant Edwards grante Yow! I guess it was all a at DREAM... or an episode of visi.com HAWAII FIVE-O...
Differences between interrupt service routine (ISR) and a subroutine
Started by ●November 28, 2006
Reply by ●November 29, 20062006-11-29
Reply by ●November 29, 20062006-11-29
In article <456cca43$1@clear.net.nz>, no.spam@designtools.maps.co.nz says...> James Beck wrote: > > > > Not really an interrupt in the hardware sense since the main line code > > knows when they are called and actually sets up registers to pass info. > > BIOS calls are really just common subroutines that are in firmware. > > Correct, but the op (or his tutor) did not say hardware interrupt. > > Also, subroutines have an address that is resolved at compile/link > time, but with a SW interrupt BIOS call, the users code has no knowledge > of the address it is (finally) calling. > > There are also system exception interrupts, that are slightly > different again.. > > It's up to the OP, to present all this in a choerent assigment.... >Very true. A good way to have entry points into an OS also....... Jim
Reply by ●November 29, 20062006-11-29
CBFalconer wrote:> rickman wrote: > > > ... snip ... > > > > I know another, the 8008. Or I may be confused, maybe it didn't have > > interrupts! It only had an 8 level hardware stack for subroutines, so > > it was pretty useless for a lot of things and was very quickly replaced > > by the 8080. > > > > In general, an interrupt without a save of the PSW is pretty useless. > > I guess you could manually save it as the first thing in the ISR, but > > that requires that the IRQ not change any status bits before the PSW > > gets saved. Otherwise anytime you want to use a status flag, you have > > to disable interrupts between the setting and the checking. > > Not in the 8008. There was no way to save the CPU state. The only > way to use the interrupt system was to reserve a register for > interrupt entry use alone.Ok, so it had an interrupt, but it was pointless because you could not save and restore the PSW. So even if you used a dedicated register, there was no way to not clobber the flags in the routine other than not using any instruction that set the flags. I see why the 8008 disappered so quickly!
Reply by ●November 29, 20062006-11-29
rickman wrote:> Tom Lucas wrote: > >>"Neil" <NeilKurzm@worldnet.att.net> wrote in message >>news:JY9bh.384791$QZ1.43268@bgtnsc04-news.ops.worldnet.att.net... >> >>>Tom Lucas wrote: >>> >>>>>- the CPU flags are stored on the stack in addition to the return >>>>>address >>>> >>>>That is true (although I suspect some pedants will find an example of >>>>systems that don't). >>>> >>>> >>>> >>> >>>The PIC the 8052 >> >>There's always bloody one isn't there ;-) Are you sure about the PIC? > > > I know another, the 8008. Or I may be confused, maybe it didn't have > interrupts! It only had an 8 level hardware stack for subroutines, so > it was pretty useless for a lot of things and was very quickly replaced > by the 8080. > > In general, an interrupt without a save of the PSW is pretty useless. > I guess you could manually save it as the first thing in the ISR, but > that requires that the IRQ not change any status bits before the PSW > gets saved. Otherwise anytime you want to use a status flag, you have > to disable interrupts between the setting and the checking.The 8051 leaves the PSW pop up to the user, and in an embedded microcontroller, that makes good sense. [ A good compiler will warn if you use something that has not been saved :) ] Why is it a good idea ? : In the case of the 80C51, it is possible, and practical, to have functional interrupts that do not pop the PSW. Also, INT response time can be important, ( to say a pin change ) and in an 80c51 that can be done first, then the PSW popped. These chips were designed when cycles and bytes mattered. -jg
Reply by ●November 29, 20062006-11-29
2005 wrote:> Hi > > What are the differences between ISR and a subroutine in embedded > systems, how about the following: > - interrupts are disabled by the microprocessor prior to calling the > isr > - isr's are always smaller > - an isr cannot be written in C > - a subroutine always has arguments > - the CPU flags are stored on the stack in addition to the return > address > > Thanks >This sounds like homework ?.... The key difference is that an isr must always store the processor status on entry, then restore it on exit. A subrouting function call doesn't necessarily need to. Both save the current program counter on entry and restore on exit To get an idea why, look at something like the 68000 programmers reference manual - it's in pdf on the Freescale website. Chapter 5, exception processing... Chris
Reply by ●December 1, 20062006-12-01
In article <3k9qm2lp5khtg0oiish95vq5p843p1fjm3@4ax.com>, Paul Keinanen says...> On Tue, 28 Nov 2006 19:37:46 GMT, "Wilco Dijkstra" > <Wilco_dot_Dijkstra@ntlworld.com> wrote: > > > > >Well I can see some good uses for interrupts with arguments, > >making interrupt routines even easier to write in C. I'm sure > >someone has patented the idea already as it is quite obvious... > > The only use I could think of is that you have multiple interrupt > sources on the same interrupt vector, thus the hardware delivered > argument would identify which interrupt source activated the ISR. The > argument could be the card slot, the I/O or (low bits of the) memory > address of the controller etc.Or you could pass information from the interrupt source, say the converted A/D value or the CAN message box that just got filled. Robert -- Posted via a free Usenet account from http://www.teranews.com
Reply by ●December 2, 20062006-12-02
Paul Keinanen wrote:> On Tue, 28 Nov 2006 19:37:46 GMT, "Wilco Dijkstra" > <Wilco_dot_Dijkstra@ntlworld.com> wrote: > > > > >Well I can see some good uses for interrupts with arguments, > >making interrupt routines even easier to write in C. I'm sure > >someone has patented the idea already as it is quite obvious... > > The only use I could think of is that you have multiple interrupt > sources on the same interrupt vector, thus the hardware delivered > argument would identify which interrupt source activated the ISR. The > argument could be the card slot, the I/O or (low bits of the) memory > address of the controller etc.That's exactly how interrupts on S/360..zSeries have worked for the last 40 years. There's a single I/O interrupt, and it stores the 16 bit device ID generating the interrupt, along with a status word and (sometimes) the address being executed in the I/O channel program that caused the interrupt. Message Signaled Interrupts do about the same on PCI (although the ID is somewhat arbitrarily assigned by the OS to the device). For non-MSI PCI you could trivially store the bus/slot/interrupt pin (total of 15 bits) to identify where the interrupt came from. You'd still have to understand the relationship between the 1-8 functions on a card and the (four) interrupt pins.
