Re: 1teraflops cell processor possible?

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.

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.

Nick> TLB misses are similarly easy to deal with

I disagree.

I'd like to handle TLB misses by having an SMT-like core launch a little
thread which loads the necessary entry into the TLB.  The idea here is
that the main thread can continue, and TLB misses can be parallelized to
some extent.  If/when the TLB miss escalates into a page miss or
something else which requires rescheduling the main thread, the
threadlet serializes with any other threadlets, then shuts down the main
thread and jumps into the O/S to handle the resynchronization.

(That "serialize with other threadlets" gets sticky.)

I do like the idea of building FPUs that can handle denorms and Inf and
so forth in hardware with no scheduling change, just because these would
wipe out a major category of performance instability and also some
instruction scheduling headaches.

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.