Usenet.com

www.Usenet.com

Group Index

Comp Thread Archive from Usenet.com

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

Re: 1teraflops cell processor possible?



In article <[EMAIL PROTECTED]>,
Iain McClatchie <[EMAIL PROTECTED]> wrote:
>Nick> My solution to that was an architectural requirement for a 'yield'
>Nick> instruction to be called every (say) M instructions or N memory
>Nick> references, whichever comes first, and to abort the process if it
>Nick> failed to do so.  Dead easy to implement.
>
>So consider a machine which, every M cycles, inserts a "yield"
>instruction into the instruction stream.  This happens in instruction
>fetch, and there is no PC associated with the yield.

It could be done, but doesn't provide any of the advantages of a
visible yield, such as the ability to have a lot of registers without
a very large context.  Or instruction sequences that can't be split,
so that they can pass hidden data (think prefetch etc.)  And so on.

>Now you don't have to worry about proving that code paths have length
>M or less and so forth.  My guess is that compilers would end up forced
>to stick yield instructions into nearly every basic block, which would
>be a bummer.

No, they wouldn't.  There are a lot more small basic blocks caused by
conditionals (including conditional functions) than you think.

>Nick> TLB misses are similarly easy to deal with
>
>I disagree.

Well, it has been done very successfully, very often.  It was a solved
problem before 1970.

>Nick> and machine checks are separated into 'process abort' ones and
>Nick> ones fixed up in hardware and queued to a separate thread for
>Nick> logging.
>
>How big is the queue?  What happens when it overflows?  Interrupts are
>pretty nice for all these things where hardware provides finite
>resources and software virtualizes them to appear infinite.

Exactly the same as when the interrupt rate exceeds the capability of
dealing with on current systems, except that it is rather easier to
detect and handle.  In particular, aborting the process that queues
such a machine check when the queue becomes full is likely to kill
the right process; current mechanisms more often kill the system.


Regards,
Nick Maclaren.



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


Usenet.com



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