Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!agate!pasteur!ames!elroy!cit-vax!ucla-cs!oahu!frazier
From: frazier@oahu.cs.ucla.edu (Greg Frazier)
Newsgroups: comp.arch
Subject: Re: 16 & 32 bit vs 32 bit only instructions for RISC.
Message-ID: <9802@shemp.CS.UCLA.EDU>
Date: 27 Feb 88 22:18:20 GMT
References: <2574@im4u.UUCP> <3508@killer.UUCP>
Sender: news@CS.UCLA.EDU
Reply-To: frazier@oahu.UUCP (Greg Frazier)
Organization: UCLA Computer Science Department
Lines: 57

In article <3508@killer.UUCP> elg@killer.UUCP (Eric Green) writes:
>in article <2574@im4u.UUCP>, rajiv@im4u.UUCP (Rajiv N. Patel) says:
>>    bit instructions are very useful and the additional amount of time which
>>    one may incur in decoding 16 and 32 bit instructions could be offset by
>>    the time saved in fetching instructions from memory/cache assuming a 32
>>    bits wide bus. The fixed instruction architectures never seem to talk
>>    about the memory traffic involved for getting all the leading zeros and
>>    unnecessary third register name.
>
>The operative parameter here is, is the bus width {n:n>1) times greater than
>the instruction width? If so, then it doesn't matter how large the
>instructions are -- you'll always be able to fetch multiple instructions
>faster than you can execute them. For example, what you mentioned -- a 32 bit
>
>And then there is the case of cache. Whenever you fetch an opcode out of cache
>memory, you have no delays anyhow.  Someone from ?Pyramid? posted about their
[cut explanation]
>
>So, while 16-bit variable-length instructions with a 32-bit data bus may be a
>win on a machine with slow memory access time and no cache (i.e. your typical
>microcomputer, at the moment), 32-bit fixed length instructions with a 64-bit
>instruction-fetch memory interface will blow it into the weeds come
[cut some more]
>
>--
>Eric Lee Green  elg@usl.CSNET     Asimov Cocktail,n., A verbal bomb
>{cbosgd,ihnp4}!killer!elg              detonated by the mention of any
>Snail Mail P.O. Box 92191              subject, resulting in an explosion
>Lafayette, LA 70509                    of at least 5,000 words.

Eric has a good point about the cache.  However, if one is using
both 16 and 32 bit instructions, and 70-90% of the instructions
are the shorter ones, then you are going to be able to fit almost
twice as many instructions into the instruction cache.  Indeed,
when the RISC group went on to implement a RISC instruction cache
(Architecture of a VLSI Instruction Cache for a RISC", Patterson,
   et. al., 10th Annual Symposium on Comp. Arch.), they went to
the mixed-instruction length format, in order to improve its
performance.  They did expand the instructions on the back end of
the cache, partly in order to keep the same CPU hardware.

If one states the RISC philosophy as optimizing those aspects of the
CPU/instruction set which are used the most often, then it very
much make sense to make the instructions executed 70-90% of the time
16 bits.

In any case, if one is going to have a dedicated, off-chip instruction
cache, then the benefits of having 16-bit instructions is rather
minimal.  However, if one is going to have a combined instruction/data
cache, or if one is going to have an on-chip instruction cache,
then the amount of memory required to achieve a good instruction
hit ratio is very important, and having 16-bit instructions should
be a real win.
Greg Frazier	    o	Internet: frazier@CS.UCLA.EDU
CS dept., UCLA	   /\	UUCP: ...!{ihnp4,ucbvax,sdcrdcf,trwspp,randvax,ism780}
	       ----^/----					!ucla-cs!frazier
		   /