Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!voder!apple!bcase
From: bcase@Apple.COM (Brian Case)
Newsgroups: comp.arch
Subject: Re: 16 & 32 bit vs 32 bit only instructions for RISC.
Message-ID: <7576@apple.Apple.Com>
Date: 7 Mar 88 02:11:40 GMT
References: <2574@im4u.UUCP> <9740@steinmetz.steinmetz.UUCP> <7538@apple.Apple.Com> <479@imagine.PAWL.RPI.EDU>
Reply-To: bcase@apple.UUCP (Brian Case)
Organization: Ungermann-Bass Enterprises
Lines: 22

In article <479@imagine.PAWL.RPI.EDU> beowulf!lunge!jesup@steinmetz.UUCP writes:
>	Also, if this is NOT an embedded system, you have to worry about
>bus bandwidth.  How many 40 Mhz busses are there?  Not many.  By using

There aren't many 80 MB/sec system buses either.  Even without an embedded
environment, you'll have to have dedicated memory paths or caches.

>16-bit instructions we cut the bandwidth required (at least at the chip
>edge, corresponding drops farther down) for instructions from 160 megabytes
>per sec to 80 MB/sec.  That means that on-board caches will fill twice
>as fast (for the same number of instructions).

Yes, but my guess is that the number of instructions isn't the same; that is,
there are more of your shorter instructions.  You're right, there won't be
twice as many, but, as I have said before, I believe the solution is not
to cut the bandwidth requirements but to provide the required bandwidth.
Note that since the RPM40 has a TIB, you could have two-way interleaved
your external instruction memory.  This would have:  loosened the
requirement for 16-bit instructions, required twice as many external
instruction chips, increased the size of your TIB (but not double since
the tag store doesn't increase in size), and required that the I-bus run
at 40 MHz instead of 20 MHz.  I suspect that twice the external RAMs would
be the problem.