Re: Pipeline flushing in processors

isn't there more than one factual inaccuracy here?

a) implication that interrupts and exceptions always flush

b) for precise interrupts execution continues normally, 
whatever that means (no flush?)

c) you can only flush if you use a plunger. I normally use 
the lever on the left, sometimes one in the middle.. hmm.. 


Are we discussing a "siphonic flush"  or "washdown flush"? 
(interesting side note on siphonic: Joseph Adamson patent, 
eight years before Crapper got his s**t together..yet Crapper 
gets all the glory). 

In all seriousness, there are no processors that flush pipelines 
anymore. Large teams are assembled in remote villages, that design 
logic to resolve all pipeline hazards and cancellations without flushes. 
Using flushes nowadays is acknowledged to be less than manly. 

Resort to flushes for exceptions? You might as well say you hit the 
power off button.

See siphonicbench, for a comparison of the exception thruput and latencies.

The latest chips have reduced exception latency by approx. 3.47 ns. 
thru the use of modern non-flushing techniques.

This is an especially important feature, and has been heavily discussed
in comp.arch (pre '84) and as a result is implemented in all modern
processors.

Now of course I am only discussing superscalar processors. 
We all know the issues are different for lessthanscalar processors, 
and siphonic flushes are common, and used to resolve things like 
carry propagation, regfile writes, dynamic ram refresh, 
vertical acceleration, barometic pressure changes, and thermal relief.


In fact, when you hit refresh on a browser window, most processors 
excecute the special "SiphonicFlush" command 17 times in quick 
succession. (17 is required due to DOD regulations about eliminating 
any remnants of POPC execution).

Flushes are used to insert bugs in processors mostly nowadays
(i.e. designers are only allowed to insert accidental flushes) 
...for instance, this reference in gcc:

+   /* Work around the pipeline flush that will occurr if the results of
+      an MM instruction are accessed before the result is ready.  Intel
+      documentation says this only happens with IALU, ISHF, ILOG, LD,
+      and ST consumers, but experimental evidence shows that *any* non-MM
+      type instruction will incurr the flush.  */


The IALU, etc references however prove that carry propagation is 
resolved thru pipeline flushes.

Oh yeah, did you know the MTBF of most TB flappers is only ~5 years?
Another reason why flush reduction is an important part of computer
architecture nowadays...increased focus on reliability.

-lev

[EMAIL PROTECTED] (Nick Maclaren) wrote in message news:<[EMAIL PROTECTED]>...
> In article <[EMAIL PROTECTED]>,
> "Peter L. Montgomery" <[EMAIL PROTECTED]> writes:
> |> >[EMAIL PROTECTED] (Ameet) writes:
> |> >
> |> >> Wehnever a interrupt or any other exception occurs in superscalar
> |> >> processors, the pipeline is "flushed". Can anybody guide me on these
> |> >> two questions:
> |> >> 
> |> >> 1. When is a pipeline flushed? For some interrupts (precise
> |> >> interrupts) the execution continues normally;
> |> >> so what are the instances when the pipeline is flushed?
> |> 
> |>          When you use a plunger.
> 
> Being a kind-hearted soul, I am always happy to give people help
> with their homework, so here is a clue:
> 
>     In the question above, there is a factual inaccuracy.  Find
>     it first, correct the question, and THEN try to answer it.
> 
> 
> Regards,
> Nick Maclaren.