Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!a.gp.cs.cmu.edu!koopman
From: koopman@a.gp.cs.cmu.edu (Philip Koopman)
Newsgroups: comp.lang.forth
Subject: Re: Cost of Forth Chips
Message-ID: <5902@pt.cs.cmu.edu>
Date: 18 Aug 89 11:25:03 GMT
References: <893@mtk.UUCP> <21351@cup.portal.com> <5882@pt.cs.cmu.edu> <26815@amdcad.AMD.COM>
Distribution: usa
Organization: Carnegie-Mellon University, CS/RI
Lines: 24

In article <26815@amdcad.AMD.COM>, tim@cayman.amd.com (Tim Olson) writes:
> What pipeline state do you need to save when responding to an interrupt? 
> Everything in the pipeline before the "commit point" is flushed, while
> everything after the commit point continues on through the pipeline. 
> This all happens pretty much instantaneously.

If you choose to flush your pipeline because it is cheaper than
saving the state of it (which makes a bit of sense), you still have
an interrupt latency that reflects the time spent refilling the pipeline.
AND, you have a built-in latency for processing the interrupt that
reflects the time it takes for the interrupt service instructions
to get through the pipeline.

Now, if a few microseconds for an interrupt latency is OK, then
pipelining works fine.  But, if you want faster interrupt response,
you have a problem.  The RTX 2000 takes 4 clock cycles (400 ns) between the
time an interrupt is asserted on a pin until it is actually executing
the first interrupt service instruction.

  Phil Koopman                koopman@greyhound.ece.cmu.edu   Arpanet
  2525A Wexford Run Rd.
  Wexford, PA  15090
Senior Scientist at Harris Semiconductor.
I don't speak for them, and they don't speak for me.