Conference hydra::amiga_v1

    It is not the case that after a hardware interrupt return is always
    made to the point of interruption.  In general, exit from an interrupt
    is made through "the scheduler", which decides which task to run next.
    If it decides to run the task that was running when the interrupt
    was taken, then return is to the point of interruption.  However,
    if the interrupt code modified some data that the scheduler examines
    when making its decision about which task to run next, then return
    could be made to a different place.
    
    An example of this is a task which calls a subroutine in the operating
    system to read a block of data from a floppy disk.  The subroutine
    gets the hardware started, sets a flag to indicate that the task is
    "blocked", and branches to the scheduler to find a task to run.
    When the hardware completes the operation it interrupts whatever task
    is running, and the interrupt code clears the "blocked" flag, which
    permits the scheduler to allow that task to continue execution.
    
    This "scheduling" approach allows one task to run while another
    waits for I/O or for user input.  The running task doesn't need to
    include calls to the scheduler in its long-running compute bound
    loops---those calls are performed by the interrupt code.
    
    The above description is not specific to the Amiga's operating system.
    The same theory is used by all multi-tasking operating systems that
    I have studied---STSS (PDP-1), MCP (B5000), OS/360 (IBM 360), 
    TOPS-10 (PDP-10), RSX-11M (PDP-11) and VMS (VAX).  The technique has
    become so well accepted that it has practically become the definition
    of multi tasking.
        John Sauter

    thanks for your reply. 
    it's hard to visualize, especially when you consider that a 'task'
    is a piece of code that the cpu is either executing or not. in other
    words, all 'tasks' are really just different states of the current
    cpu - there's only one cpu, not one per task.
    
    for example, let's suppose there is only one task, and no scheduler;
    just a simple loop that's executing over and over:
    
    start_loop:
    .
    .
    .
    end_loop;                                        
    
    now suppose we hit a hardware interrupt, say an invalid op-code:
    
    start_loop:
    .
    .
    instruction_a:
    instruction_b:
    .
    .
    end_loop:
    
    in the above, instruction_a is actually an invalid op-code.
    
    now the cpu branches to the interrupt handler for this interrupt:
    
    start_handler:
    .
    .
    .
    RTI
    
    how can the interrupt handler do anything other than return to
    instruction_b in the previous code?
    
    i don't know assembler; can you specify where the interrupt handler
    - that chunk of code that the cpu is directed to execute on the
    given interrupt - should return to? that seems to be what your saying,
    that instead of
    
    RTI
    
    you can have
    
    RTI <address>,
    
    or somehow setup the return address before RTI.
    
    
    
    Boy this is a pretty wandering question. if you can figure out what
    i'm asking, that would be great; if not, i'll burrow around in some
    68000 assembler manuals. my question, upon reflection, is really
    not an operating system question, but a cpu/hardware question -
    the lowest possible level.
    
    thanks again.
    
    ken
    
    
    

    
    Suppose part of what that interrupt routine does is change the stack
    pointer.  Then the RTI goes somewhere else...
    
    -steve

Even if your RTI has to go back to the original code, an interrupt-driven
system will still get more throughput than one that uses polling for IO
completion.

First, note that on most systems, task scheduling also happens on return
from a system call. Since many system calls cause a change in a tasks state,
this is just about required.

If you've got the BD RTI-must-return to caller, you can still do non-preemptive
multitasking. In this case, the only scheduling is done on system calls.
All the interrupt handling code does is toggle bits and possibly move
tasks around in the queues. When the program that was running calls the OS,
the scheduling will happen, and something else may get to run before the
system call returns to that task.

What this means is that, for every pending event, you get a burst of activity
when the event happens. Compare this to polling, where you chew up a fixed
percentage of the CPU doing the polling until the event happens, and still have
to do the resched when it happens. The polling may take less CPU, but if you
get a number of them going (one on disks, one on the keyboard, and one on
the serial port because you're logged in elsewhere while doing background
compiles), the overhead on the system might be noticable. There won't be any
extra overhead on the interrupt-driven machine until the event happens.

	<mike

    re: .3, .4
    
    The critical thing to remember is that each task has its own stack.
    When the scheduler decides to run a particular process it loads the
    processor's stack pointer register from the place where it was saved
    when this task last ran.  All of the other user-mode registers are
    also saved and restored in this manner, so if you are writing code
    to run as a task you can depend on the registers not changing due
    to an interrupt, even if that interrupt causes a different task to
    run for a while.
    
    After the stack pointer register is loaded, the instruction which
    returns from the interrupt will return to the desired task.
    
    Not all machines have instruction sets which deal with stacks
    explicitly.  Those multi-tasking operating systems which run using
    such non-stack-aware instruction sets simulate the stack using other
    instructions.
        John Sauter

    It is important to remember that the Amiga is (more than anyother
    machine you have probably seen) a true Hardware "DISTRIBUTED" arch.
    As an example, if you obey the normal system rules about EXEC, then
    the 68000 only responds to two interrupts, non-maskable and software.
    The other interrupts are handled by exec and you must place your
    interrupt routines in the exec queue to be processed (as per their
    priority).
    
    If the question is why is an interrupt structure higher in thruput
    than a polling system the answer is that it is ansynch to the needs
    of the resources (responds when needed).  Polling PREVENTS you from
    responding when NEEDED and requires you to only respond when the
    current resource request is satisfied.
    
    If the question is HOW do you create an interrupt structure that
    does not return to the same place after a interrupt occurs (or better
    question...what state does a machine have to be in to allow interrupts)
    then you might want to examine the instruction arch of several
    different machines.  Some machines institute a non-interruptable
    instruction (the interrupt is held off until completion of the
    instruction).  Others enforce the structure of the environment and
    require you to not alter the environ at all, etc.  There are lots
    of ways to do this interrupt stuff.
    
    For an excellent discussion of the exec and the interrupts arch
    on the Amiga, you might read a book by Carl Sasenrath called Guru
    Medatations #1 ($15.00 [US] about and if you can't find it, just
    send me mail and I'll get you the address of a place you can obtain
    it).  Carl designed and helped code the EXEC for the Amiga and his
    explanations are crystal clear!
    
    Holler if there are any questions.
    
    TOPGUN
    

    i'm going to extract all these replies and try to understand 'em.
    
    thanks for all this meaty info!
    
    ken

    It should also be pointed out that a major feature of interrupts is
    preventing data overrun or other errors where an asynchronous event is
    not serviced in time. Interrupt routines are designed to capture
    volatile data including state and then schedule further processing.
    Systems that poll and are used for general processing are difficult to
    implement because it is diffcult to enforce the minimum time between
    polling cycles. Real time systems that require very fast response times
    can sometimes do better by polling because they do not have to suffer
    the overhead of the required context switching to service the interrupt. 

    Hope this adds some more incite into the value of interrupts.

    -Tom-