Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!msp33327
From: msp33327@uxa.cso.uiuc.edu (Michael S. Pereckas)
Newsgroups: comp.arch
Subject: Re: RISCizing a CISC processor
Message-ID: <1990Dec7.192707.10303@ux1.cso.uiuc.edu>
Date: 7 Dec 90 19:27:07 GMT
References: <9012070105.AA02416@hcrlgw.crl.hitachi.co.jp> <1990Dec7.061826.28241@ux1.cso.uiuc.edu> <2339.275f7e44@iccgcc.decnet.ab.com>
Sender: news@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at Urbana
Lines: 50

In <2339.275f7e44@iccgcc.decnet.ab.com> herrickd@iccgcc.decnet.ab.com writes:

>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.


But then it wouldn't be compatable anymore.  What's the point?  It
might be possable to design a system that allows you to automagically
translate a binary compiled for the old CISC, but I suspect that this
would be very hard to do and that it wouldn't work very well.  And
chances are that no body would want to use it.  If the translator is
imperfect (likely) then end-users won't want to try it and probably
couldn't (no sources to work from).  The vendor might well decide it
would be easier to port it to a normal RISC.  This might make it
easier to port stuff written is assembly, but then, you wrote it in
assembly to get speed, right?  Rewrite it for the RISC and it will go
faster.  

--


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