Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!ukc!acorn!armltd!abaum
From: abaum (Allen Baum)
Newsgroups: comp.arch
Subject: Re: VISC - speeding up moto cisc mpu's?
Message-ID: <177@armltd.uucp>
Date: 20 May 91 10:22:34 GMT
References: <2786@lee.SEAS.UCLA.EDU>
Sender: abaum@armltd.uucp
Distribution: comp
Organization: A.R.M. Ltd, Swaffham Bulbeck, Cambs, UK
Lines: 27


>I think it would be more in line with RISC philosophy to rip out as
>much of the CISC core as possible, leaving close to the bare minimum of 
>what is needed to emulate via software traps those addressing modes that 
>would be deleted (most) and those instructions that would be deleted 
>(anything that compilers are staying away from, up to the neck of the 
>curve).
>
>This is how many FPU ops in the 68040 are implemented, and the strategy 
>seems to have been successful, if SPEC numbers are worth their salt.  

Actualy, there are several reasons the '040 SPEC numbers are better-

1- faster clock, resulting from better process technology,
2- better compilers
3- tightly integrated FPU (means less cycles wasted on instruction
  decoding & overhead as opposed to computation
4- better FPU - fewer cycles needed for ops that are used.

While ripping out the unneeded stuff may contribute to 1, and to 4,
you may find the bulk of the differences don't; i.e. if you put in
all those CISCy ops, it wouldn't run significantly slower.

All that, of course, presupposes that (a) you can fit this expanded
function on the chip, and (b) you would have finished debugging it
before you ran out of development funds. This, to my mind, is the
really big win for RISC, and virtually guarantees a speed advantage.