Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/13/84; site intelca.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!whuxl!houxm!ihnp4!pesnta!amd!intelca!kds
From: kds@intelca.UUCP (Ken Shoemaker)
Newsgroups: net.micro.68k,net.arch
Subject: Re: Re: RISC
Message-ID: <4@intelca.UUCP>
Date: Fri, 21-Jun-85 16:32:17 EDT
Article-I.D.: intelca.4
Posted: Fri Jun 21 16:32:17 1985
Date-Received: Sun, 23-Jun-85 04:27:04 EDT
References: <639@vax2.fluke.UUCP> <2743@nsc.UUCP> <576@terak.UUCP> <5691@utzoo.UUCP>
Organization: Intel, Santa Clara, Ca.
Lines: 23
Xref: watmath net.micro.68k:951 net.arch:1453

> introduce another level of emulation.  The point is that the poor code
> density of current RISCs is the result of optimization for experimental
> work rather than production.  More compact encodings, without change to
> the basic concept, are both possible and desirable once the basic issues
> are understood.
> -- 
> 				Henry Spencer @ U of Toronto Zoology
> 				{allegra,ihnp4,linus,decvax}!utzoo!henry

er, I don't think so...one of the basic concepts of RISCs as I understand
them is to reduce the number of pipeline stages in the execution of
instructions.  Adding another just to do an expansion/shuffleing of
of opcode bytes flys directly in the face of that thinking.
-- 
...and I'm sure it wouldn't interest anybody outside of a small circle
of friends...

Ken Shoemaker, Microprocessor Design for a large, Silicon Valley firm

{pur-ee,hplabs,amd,scgvaxd,dual,qantel}!intelca!kds
	
---the above views are personal.  They may not represent those of the
	employer of its submitter.