Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!ji.Berkeley.EDU!melvin
From: melvin@ji.Berkeley.EDU (Steve Melvin)
Newsgroups: comp.arch
Subject: Re: VAX Architecture (Was: Re: Slandering Intel)
Summary: Decoded Instruction Cache
Message-ID: <29562@ucbvax.BERKELEY.EDU>
Date: 9 Jun 89 16:12:24 GMT
References: <76700071@p.cs.uiuc.edu> <3335@cps3xx.UUCP> <19255@cup.portal.com>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: melvin@ji.Berkeley.EDU.UUCP (Steve Melvin)
Organization: University of California, Berkeley
Lines: 18

In article <19255@cup.portal.com> bcase@cup.portal.com (Brian bcase Case) writes:
>Someday DEC will implement a parallel
>instruction decoder along the lines of the one used in the 486 (but
>much more complex).  Then they will be able to lower the CPI of
>the VAX.

You're ignoring the most obvious solution: a decoded instruction cache.
With this, the time to decode becomes an instruction cache miss effect
and in the case of a hit, an entire instruction (or more) can be pulled
out of the cache in a single cycle.  Decoding should still be fast, but
with a large enough cache, it's not as critical.  (Now the problem becomes
how to keep those darn REI's from flushing the cache, ... how about a
new non-flushing REI instruction?)

----
Steve Melvin
melvin@ji.Berkeley.EDU					...!ucbvax!melvin
----