Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!uunet!ogicse!cvedc!mcspdx!adpplz!martin
From: martin@adpplz.UUCP (Martin Golding)
Newsgroups: comp.arch
Subject: Re: CISC vs. RISC Code Sizes
Keywords: CISC RISC Size CRISP MIPS R3000
Message-ID: <825@adpplz.UUCP>
Date: 20 Jun 91 17:20:57 GMT
References: <1991Jun18.132315.8202@cbnewsl.att.com> <1991Jun18.152303.1889@rice.edu> <3436@crdos1.crd.ge.COM>
Organization: ADP Dealer Services R&D, Portland, OR
Lines: 53

In <3436@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes:

>In article <1991Jun18.152303.1889@rice.edu> preston@asta.rice.edu (Preston Briggs) writes:

>|                                 Choosing the right instruction set
>| can lead to tremendous space compression (orders of magnitude).

>  I'd like to see how you got that. Even if you had a CPU which used LZW
>or Huffman code as opcodes, I don't think you see even one order of
>magnitude. 

The Pick operating system, it its original machine code, requires slightly
less than .5 Meg of memory. It expands 4 to 6 times on CISC machines, and 
8 to 12 times on RISC machines; ie: 1 order of magnitude. The instruction
set was designed simultaneously with the system, and is the most C of all
the ISs I've ever seen on a C. 

Details, of course, are proprietary.

>Note that this is hard to measure, since any object files
>almost always contain data. 

But not more than a percentage, so the one order of magnitude is plus
some insignificant amount (or even a significant amount, but certainly
not 2 orders of magnitude).

>Still, no compression method operating on
>either RISC or CISC code will give anything like even one order of
>magnitude, so I don't see that using an interpreted language will save
>that much. If it will maybe you've hit on another data compression
>scheme.

This isn't a process of data compression, it's a process of function
compression, ie, each instruction encodes a series of machine operations.
For a clear and RISC type example, take a look at your generated assembly
code, and estimate the resulting size increase if you removed address
calculation from all of the load/store instructions.

To make use of such an instruction set, you need either a high level
source language or you need a 'vectorizing' compiler, ie, one that
can infer a single high level operation out of a series of low level ones.
Or, you can write everything in assembler, which is sufficiently
productive if your machine language is of a much higher order than
the available high level language.

I'll always wonder whether the world would be substantially different,
if that original PDP11 had had the commercial instruction set.


Martin Golding    | sync, sync, sync, sank ... sunk:
Dod #0236         |  He who steals my code steals trash.
A poor old decrepit Pick programmer. Sympathize at:
{mcspdx,pdxgate}!adpplz!martin or martin@adpplz.uucp