multi/tasking/processing

[Christophe Lavarenne <Christophe.Lavarenne@xxxxxxxx>]

I agree with Penio Penev that:
> one is much better off with total control over all of the silicon ...

But his following argument is worth a comment:
> On the other hand, big states (register files) are not good for
> multitasking, since _all of them_ need to be swapped to/from memory
> _every_ context switch.  (Don't tell me, that having _only_ two tasks is
> adequate for a multitasking machine.)

You are right for monoprocessor multipurpose desktop workstations.

For multiprocessor real-time embedded machines, I would rather say that the
most efficient use of hardware is only one task per instruction sequencer, to
avoid the overhead of context switches.

On a multi-F21, there are several instruction sequencers.
Even on a single F21, there are several instruction-sequencers:
- one dealing with the ALU, decoding twenty seven 5bits instructions
- one dealing with the video output, decoding eight 5bits instructions
- one dealing with the ADC/DAC, decoding one 20bits instruction
- one dealing with the serial I/O, decoding two instructions (SOM and EOM)

All four have basic sequencing ability: fetch next instruction, decode it and
execute a state transition conditionned by the instruction code.

Only the first one has full sequencing ability: the address of the instruction
to be fetched may be conditionned by the decoded instruction and by the state.

This is why interrupts are provided to allow other sequencers to "borrow" the
first one (the ALU sequencer) to "restart" themselves at another instruction
address.  Interrupts are also used for synchronization purpose between the
sequencers.

Briefly, there are several ways to implement parallelism, the most general one
(pseudo-parallelism with context switches) being the less effective, and the
most specific one (matching the _available_ parallelism of the target
architecture) being the most efficient.