Re: 1teraflops cell processor possible?

In article <[EMAIL PROTECTED]>,
Russell Wallace <[EMAIL PROTECTED]> wrote:
>On 27 Nov 2003 20:33:49 GMT, [EMAIL PROTECTED] (Nick Maclaren) wrote:
>
>>For example, starting from the position that either HP or Intel
>>was with the IA-64, there is no reason not to consider a totally
>>interrupt-free design.
>
>How would you do I/O and pre-emptive multitasking without interrupts?

I/O is trivial; interrupts always were a bad way of doing it, and many
older systems did it other ways.  Consider, for example, I/O requests
that don't block and I/O responses that are put into a queue for
handling when the driver next gets around to it.  FIFOs are not exactly
unusual in hardware :-)

Alternatively, you can go for a seriously multi-threaded approach and
have all I/O operations blocking, so you need to spin off a new thread
for each one.  Not a major issue if you have enough threads available,
but it needs a lot of hardware threads - which is perfectly possible
on modern chips.

Multitasking was done without interrupts on quite a few of the earlier
machines - what you mean is preemptive multitasking (i.e. not the
coroutine approach).  Each process yields control when it gets to
suitable points, which are required to be no further apart than a
certain time.  Apple took that approach for a long time, and its
only problem is that a failing program can block the hardware thread.

My solution to that was an architectural requirement for a 'yield'
instruction to be called every (say) M instructions or N memory
references, whichever comes first, and to abort the process if it
failed to do so.  Dead easy to implement.

TLB misses are similarly easy to deal with, and machine checks are
separated into 'process abort' ones and ones fixed up in hardware
and queued to a separate thread for logging.  Nobody sane should
handle timers/clocks by interrupt.

So where's the problem? :-)


Regards,
Nick Maclaren.