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.