Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!rex!ukma!usenet.ins.cwru.edu!abvax!iccgcc!herrickd
From: herrickd@iccgcc.decnet.ab.com
Newsgroups: comp.arch
Subject: Re: RISCizing a CISC processor
Message-ID: <2339.275f7e44@iccgcc.decnet.ab.com>
Date: 7 Dec 90 16:34:28 GMT
References: <9012070105.AA02416@hcrlgw.crl.hitachi.co.jp> <1990Dec7.061826.28241@ux1.cso.uiuc.edu>
Lines: 37

In article <1990Dec7.061826.28241@ux1.cso.uiuc.edu>, msp33327@uxa.cso.uiuc.edu (Michael S. Pereckas) writes:
> In <9012070105.AA02416@hcrlgw.crl.hitachi.co.jp> joe@hcrlgw.crl.hitachi.co.JP (Dwight Joe) writes:
> 
[Description of RISC architecture with CISC instructions microcoded
 deleted]
> 
> 
> 
> What about instruction decode?  RICS machines tend to have
> fixed-format instructions that are easy to decode.  (i.e.  all
> instructions are 32 bits, the first 6 are opcode, the next 15 specify
> registers, the rest immediate data).  CISCs tend to have instructions
> of varying length and format.  RISCs tend to have alignment
> restrictions to a greater extent than CISCs.  You lose some of the
> benefits of RISC if you have to deal with these things.
> Does anyone know how the internals of the 80486 and 68040 compare to
> this scheme?
> --
Cannot we preserve the intent of the original poster by adding
one RISC instruction, "Nonsense Coming", that means the next
few words of instruction memory contain data to be interpreted
by the microcoded CISC program.  Constrain the length of the 
nonsense to preserve the RISC program alignment requirements.

Or, even, put the roms holding the microcode in the primary
address space of the machine and invoke these CISC instruction
subroutines the same way as any other subroutine.  With a RISC
call.

dan herrick
herrickd@astro.pc.ab.com

> 
> 
> Michael Pereckas               * InterNet: m-pereckas@uiuc.edu *
> just another student...          (CI$: 72311,3246)
> Jargon Dept.: Decoupled Architecture---sounds like the aftermath of a tornado