Path: utzoo!mnetor!uunet!husc6!purdue!decwrl!granite!paulr
From: paulr@granite.dec.com (Paul Richardson)
Newsgroups: comp.arch
Subject: Re: Proposed architecture characterization survey form
Message-ID: <219@granite.dec.com>
Date: 20 Apr 88 14:19:25 GMT
References: <2048@gumby.mips.COM> <50070@sun.uucp> <2052@gumby.mips.COM>
Reply-To: paulr@granite.UUCP (Paul Richardson)
Organization: DEC Workstation Systems Engineering
Lines: 43
Keywords: RISC


I am kind of tired of listening to these arguments of what is and what is
not a RISC machine.So that we can move onto more interesting architectural
topics I propose the follwing definition.


RISC: 
      1) A machine in which the instruction set is designed/chosen based
         on what makes the most sense to put into the hardware.For instance,
         you probably wouldn't want to piss away alot of hardware on the
         equivalent of the *VAX* POLY instruction,yet on the other hand
         optimizing load/stores might turn out to be a big performance win.

      2) Although it is not necessarily a requirement,it has been a 
         characteristic of RISC machines that they have a 'large'
	 general purpose register file.Just how many defines large
         is up to the designer but from the papers on register allocation
         I have seen (especially David Wall's) it seems that something
         between 32 and 100 is about all that current compiler technology
	 knows how to deal with

 


I have had the oppurtunity to work with one so called 'RISC' machine,
(The dec resaerch box called the TITAN) and read about many others.The
underlying similarity amongst them all seems to be that good engineering
practice was used in determing the architecture/instruction set.Doing things
like taking statisctics on what the frequency of instructioms used in REAL
programs and using that to determine what does and what does not go into the
hardware seems to make sense to me.Making compilers smarter and do things
like schedule instructions seems to make sense to me.Using registers instead
of main memory during run time makes sense to me (this is not a risc 
discovery).


OK OK OK, that's my two sense worth.Now could we talk about things like

merits of delayed branching,or limits on pipeline depth,or nifty floating
point algoritms etc...I know that there are plenty of bright people out
there just dying to spill their grey matter on other topics

/pgr