Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ll-xn!ames!lll-tis!mordor!ehj
From: ehj@mordor.s1.gov (Eric H Jensen)
Newsgroups: comp.arch
Subject: Re: 360 vs VAX stuff
Message-ID: <15619@mordor.s1.gov>
Date: Mon, 14-Sep-87 02:18:16 EDT
Article-I.D.: mordor.15619
Posted: Mon Sep 14 02:18:16 1987
Date-Received: Tue, 15-Sep-87 01:52:43 EDT
References: <818@PSUECLB>
Reply-To: ehj@mordor.UUCP (Eric H Jensen)
Organization: S-1 Project, LLNL
Lines: 31

In article <818@PSUECLB> bjj@psueclb.BITNET writes:
>The HCX7 seems to have solved the instruction decode problem with
>a separate instruction cache.  The cache contains DECODED instructions
>stored as fixed length 73 bit words.
>
>Assuming a reasonable hit ratio in the 4K word instruction cache,
>the extra complexity of instruction decode won't affect speed.

This last statement is not strictly true - refill time can be
adversely affected in the following ways:

1) In most cases there is at least one additional pipe stage to do the
decode.  If there isn't it would seem to me that there are other
problems/limitations with the arch/design.

2) Games that can be played with loading > 1 32-bit (pick your
favorite RISC) instruction simultaneously into an icache line are
2-4(*) times as 'expensive' to apply to a pre-decoded icache - 2-4x
the amount of decode logic, 2-4x the number of fast rams, 2-4x the
number of muxes (multi-set icache), etc etc.  64 bits (2*32) is a lot
more attractive than 146 bits (2*73).

3) From discussions with other designers it appears evident that
program loops can not be relied on to hide non-aggressive icache
design.  I would consider the above approach to be complex but not
aggressive.  The complexity is applied to overcome instruction set
limitations and uses up much of the design space that could be used
for an aggressive icache design.

(*) simultaneously loading 2-4 32-bit instructions seems within reason
with the ECL technologies I design with.