Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.micro.68k,net.arch
Subject: Re: RISC
Message-ID: <5691@utzoo.UUCP>
Date: Mon, 17-Jun-85 15:26:18 EDT
Article-I.D.: utzoo.5691
Posted: Mon Jun 17 15:26:18 1985
Date-Received: Mon, 17-Jun-85 15:26:18 EDT
References: <639@vax2.fluke.UUCP> <2743@nsc.UUCP> <576@terak.UUCP>
Organization: U of Toronto Zoology
Lines: 28

> My point was supposed to be that you could take a 680xx/320xx and limit
> yourself to the RISC instruction set (the "equivalent" instructions) and
> have 16-bit instructions instead of RISC's 32-bit instructions.

Try doing memory references in 16 bits on either the 680xx or 320xx.
It can't be done, because the opcode alone is 16 bits.  And you need
memory references more on the commercial machines, because the RISC's
register architecture isn't present to reduce memory usage.

> > instruction-encoding expander.  The latter function makes a large
> > difference to instruction density without introducing any extra delays.
> 
> In a microcoded cpu, the opcode is decoded and causes a sequence of
> very simple micro-instructions to be executed.
> 
> In the proposed system, the opcode is decoded and causes a sequence of
> very simple RISC instructions to be executed.

Wrong, it causes *one* very simple RISC instruction to be executed.
The expander function is purely an encoding technique, it does not
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