_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

It's interesting, especially today where even at the high level, outside of the kernel, much of today's software is almost completely interrupt driven.

There are always exceptions, but, as an example, modern GUIs are driven off of an event queue that is filled by interrupts. Various input device activities (key down, mouse move, etc.) post event structures on a queue, and the GUI code dispatches off of that. Back in the day, screen repaints were queue based as well.

On servers, the buzzword today is "asynchronous", where you have the OS waiting on socket events, that are then dispatched to the appropriate tasks. Async, event driven programming is get very main stream right now, in many domains.

That completely depends on the application. If you need a quick and predictable response to an external event, you probably need interrupts. I've worked on systems where the maximum allowed response latency was 1 microsecond. It's not practically possible to poll flags at that rate.

Use of interrupts can also make for much more power-efficient systems than polling. For example, in 1990 or so I designed a portable data logger that would put the processor (or most of it, anyway) to sleep and only wake up to service interrupts. That way, the datalogger could run comfortably for a week on a 9V battery; if I had chosen to use polling, it would only have lasted for a few hours.

Another good use of interrupts is on a system with external user code. On a PC, you can't expect every application to be nice enough to poll the hardware at the required speed, or even know what polling frequency is required.

Well.. imagine if you have a very simple real-time clock in your system, maybe it's just an accurate counter which gives a tick every second. Now imagine if a program could just read a certain memory location to read the current time.. to have the correct time in that memory location you could have a little interrupt handler and use the one-per-second tick as an interrupt. So the interrupt handler would count up the time and maintain that memory region.
It would be inconvenient to have to program that as a poll in every program you write. Although I understand that was basically how the first Macs were programmed.. all user applications had to include a regime which made sure that all the housekeeping was done.

There are interrupt-less chips out there, the Parallax Propeller for example. But it can be interrupt-less because it has eight cores, and the idea is that instead of using interrupts to handle everything you just dedicate one core to each part (or one core could poll a number of housekeeping jobs, and then you don't have to think about that in your 'main' program).

For a single-chip/core system it's difficult to do without interrupts as soon as there are any real-time issues at hand. There may be a lot of time between when action is needed, but if it then has to be handled _very quickly_ you would have to poll very often.. even if nothing happened 99.999% of the time. Add a few of those and there's nothing left for processing, even if the processor is fast.

So, two issues really.. do you really want to have to include all the necessary polling in every trivial program? And can you handle real-time demands just with polling, without wasting most of the processor's time?

Edit: Ah, I didn't notice there was already a page-full of replies to that question..

-Tor

Hi EEye, for an extreme case, reading and writing floppy disks can take one interrupt per byte, and that turns out to give very few cycles to handle each byte - you absolutely have to keep up with the disk.

There's some info at http://www.stardot.org.uk/forums/viewto ... =3&p=33412 which contains a pointer to the rather good http://beebwiki.jonripley.com/Quad_dens ... isc_access which is unfortunately offline at present. (Edit: but now found here)

Similarly, you might want to allow for keyboard input (or serial input) - catching events in an IRQ handler and placing them in a buffer is far better than writing all your programs to poll often enough not to miss anything. If your word processor is counting words or reformatting a document, you want to be able to cancel the operation.

Cheers
Ed

Another good example is making simple beeps with a speaker connected to a IO pin. On a system with fast (and predictable) interrupt handling, it is feasible to use a timer interrupt and a general purpose IO to have the CPU do this manually, while still doing other tasks at the same time. Without interrupts, it is basically impossible.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Here's a little tale from Commodore engineer Bill Herd explaining why you should use interrupts. (The 8563 is the Commodore 128's 80-column video chip.)



(snipped from http://homepage.hispeed.ch/commodore/c128_story.html)

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Lovely!

That story is funny and interesting at the same time. In my project I have a BUSY flag output from a hardware line generator. I made 2 branch opcodes that the programmer could use to test the flag. Branch if BUSY or branch if /BUSY very similar to BNE/BEQ. That way the programmer could choose to repetitively wait for the process to be done, or if it's not done you're free to do something else except send the last coordinate (which triggers the plotter and makes it busy for some cycles).

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!