Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!ucla-cs!ucla-se!turing!plinio
From: plinio@turing.seas.ucla.edu (Plinio Barbeito)
Newsgroups: comp.arch
Subject: Re: VISC - A way to speed up moto cisc mpu's?
Summary: room for another suggestion?
Message-ID: <2786@lee.SEAS.UCLA.EDU>
Date: 17 May 91 14:55:13 GMT
References: <1991May15.110000.25800@Daisy.EE.UND.AC.ZA>
Sender: news@SEAS.UCLA.EDU
Organization: SEASnet, University of California, Los Angeles
Lines: 60

In article <1991May15.110000.25800@Daisy.EE.UND.AC.ZA> mcdonald@Daisy.EE.UND.AC.ZA (Bruce J McDonald) writes:
>A way to speed up future Motorola CISC MPUs could be:
>
...
>core.  Notice that the RISC-like enhancements to the CISC core should 
>be dropped and the CISC core kept for downward compatibility only - all
>speedy execution should be handled by the RISC core.

Does having a RISC core in itself guarantee fast execution?  I thought
the reason RISC was fast was the great amount of space it freed up on
the chip that could be used to speed up basic operations.

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.  
Keeping the old CISC core would hog chip real-estate that could be 
better applied speeding up other things, like the ubiquitous
'move's, IMHO.

As to whether they should go load/store, I think it would be less
of a compatibility-kludge-nightmare to keep the move's but enlarge 
the cache to help outweigh benefits this approach might have had.  
Besides, I've always savored the fact that 68k programs have been 
consistently and significantly smaller than many equivalent RISC 
binaries.  This helps load-time performance if processes are I/O bound, 
or use slow I/O devices.  It also saves space on mass-storage devices, 
but I haven't seen these issues dealt with extensively in this group.  
Apparently, everyone buys enough RAM so that they never page fault :-)

Regarding 64-bits, in my opinion, it depends.  In the short term it 
looks like it would disproportionately raise costs and complicate 
compatibility issues.  However, if memory speeds continue to lag 
behind CPU speeds, it may eventually become the only feasible solution.
Comments?  Is everyone jumping on the 64-bit bandwagon?

>This would mean that new compilers would have to be written which would 
>be able to switch the MPU into the new mode for enhanced performance.  I
>would think that this mean a addition CCR bit but since there are slots
>available, it should be no problem.

The advantage of doing it the other way is that you don't have to rewrite 
any new software except maybe a new optimizer for your compilers. 

Interesting side-note: Since it would be cheap to add new instructions
via traps, how about putting in an opcode to speed up string comparisons 
to deny intel the ability to claim higher performance in any
benchmark category? (Flamesuit on)


plin
--
To mak wridin mo eficiend, i sujes de folouin janjs: drop deleder 'c', as 
'k' uil do jus fin.  gt rid of endn 'e', sins ids nevr pronncd aniuai.  als, 
't' is nevr nedd; us 'd'.  repeddv knsnnds shd b nls bpp ngbbl rr...01011101