Usenet.com

www.Usenet.com

Group Index

Comp Thread Archive from Usenet.com

<-- __Chronological__ --> <-- __Thread__ -->

Re: 1teraflops cell processor possible?



On 28 Nov 2003 09:05:07 GMT, [EMAIL PROTECTED] (Nick Maclaren) wrote:

>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.

True, those would work.

>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.

Yeah... that's a showstopper unfortunately, at least on a
general-purpose machine that's going to have to run a random
collection of programs, many of them badly written.

>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.

Hey, that's a good point. Just have a counter count down on each
instruction executed... that would work.

>So where's the problem? :-)

Okay, problem solved ^.^

-- 
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace



<-- __Chronological__ --> <-- __Thread__ -->


Usenet.com



Please check out one of the premium Usenet Newsgroup Service Providers below for access to Usenet.