Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!mintaka!mit-eddie!uw-beaver!rice!asta.rice.edu!preston
From: preston@asta.rice.edu (Preston Briggs)
Newsgroups: comp.arch
Subject: Re: CISC vs. RISC Code Sizes
Keywords: CISC RISC Size CRISP MIPS R3000
Message-ID: <1991Jun18.152303.1889@rice.edu>
Date: 18 Jun 91 15:23:03 GMT
References: <1991Jun18.132315.8202@cbnewsl.att.com>
Sender: news@rice.edu (News)
Organization: Rice University, Houston
Lines: 30

wkk@cbnewsl.att.com (wesley.k.kaplow) writes:

[yet another code size comparison]

>Results:
>		Benchmark	MIPS Code Size/CRISP Code Size
>		----------------------------------------------
>		   BSC			    1.83
>		Dhrystone		    1.84
>		   RP			    1.67

...

>As well as bytes/instruction average, we compared the static instruction
>count as well.  In our study we found that:
>
>		Extra Instructions % in MIPS = 44%.

Again, we'd _really_ like to see instruction counts.
I know the MIPS compiler unrolls loops, at least sometimes.
This alone makes me doubt the validity of any static instruction counts.

An earlier poster noted that sometimes code size dominates all other
considerations.  In this case, we should consider an interpreter.
Forth is one example.  To an extent, CISC machines (with microcoded
implementations) are another.  Then there's table-driven scanners, parsers,
code generators, and so forth.  Choosing the right instruction set
can lead to tremendous space compression (orders of magnitude).

Preston Briggs