Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!bbn!rochester!cornell!batcomputer!itsgw!imagine!pawl23.pawl.rpi.edu!jesup
From: jesup@pawl23.pawl.rpi.edu (Randell E. Jesup)
Newsgroups: comp.arch
Subject: Re: 16 & 32 bit vs 32 bit only instructions for RISC.
Message-ID: <479@imagine.PAWL.RPI.EDU>
Date: 5 Mar 88 08:57:27 GMT
References: <2574@im4u.UUCP> <9740@steinmetz.steinmetz.UUCP> <7538@apple.Apple.Com>
Sender: news@imagine.PAWL.RPI.EDU
Reply-To: beowulf!lunge!jesup@steinmetz.UUCP
Organization: RPI Public Access Workstation Lab - Troy, NY
Lines: 26

In article <7538@apple.Apple.Com> bcase@apple.UUCP (Brian Case) writes:
>>Dedicating 64 pins purely to instruction fetch (assuming a Harvard
>>architecture) is quite a lot of a rather scarce resource. Sure
>>you wanna do this on a micro ?

>Sounds like it might be a good idea.  Note that instruction-only-bus pins
>are INPUT-only; thus their corresponding pads are much "faster" and simpler
>than bidirectional bus pads.

	Pads aren't the limiting factor, but PINS (and bandwidth) are.
The RPM-40 has 144 'pins' (not PGA, but leadless chip carrier), which was the
biggest certifed package we could find.  We would KILL for more pins!
(Of course, by now there are probably larger certified packages.)

	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
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).

     //	Randell Jesup			      Lunge Software Development
    //	Dedicated Amiga Programmer            13 Frear Ave, Troy, NY 12180
 \\//	beowulf!lunge!jesup@steinmetz.UUCP    (518) 272-2942
  \/    (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup

(-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)