Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucsd!helios.ee.lbl.gov!pasteur!agate!web-1c!laba-3en
From: laba-3en@web-1c.berkeley.edu (Raja S Kushalnagar)
Newsgroups: comp.sys.amiga.hardware
Subject: 68040 vs RISC
Message-ID: <1990Feb2.073513.29698@agate.berkeley.edu>
Date: 2 Feb 90 07:35:13 GMT
Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44)
Reply-To: laba-3en@web-1c (Raja S Kushalnagar)
Distribution: usa
Organization: University of California, Berkeley
Lines: 50

While writing and analyzing the RISC II fpu last summer, under my prof,
there were several interesting things to be noted - of the RISC vs CISC. 

Pipelining is inherently much easier on the RISC, and can be carried
on to many stages easily owing to the reduced instruction set and the fixed
length of the instructions, as opposed to the CISC's.  Also, it is much 
easier to implement window register meshing on RISC's.  Those two factors 
alone, atleast in the original Berkeley RISC II, were responsible for about
40% of the speedup. Add much more efficient compiling, as was done with the
Stanford MIPS design, and that would account for most of the speedup in 
today's Sparcs and Mips, along with the r.i set.  

The Motorola 68040, if what I've been reading about here is to be believed,
has almost been able to surmount the difficulties of deep pipelining, though
it seems not to have surmounted the issue of efficient window register 
meshing, and probably might not be able to get over it at all, unless it 
goes more the RISC way, which it already seems to be going towards, but while
retaining all the advantages of CISCs.  If that can be done, it should really
perform well. But if it can't really address the issue of utilizing 
overlapping registers and frames, I wonder if it could improve quickly enough
to match the RISCs.  Then perhaps there might not be a 68050. :(  The present
1.2 million transistors on chip is remarkable though - it could improve that 
way? 

The same source code when compiled under a DEC 3100 (RISC technology) produced
binaies that were usually about 30-40% larger than those compiled under a Sun
 4/260 (CISC technology) - but with the prices of RAM being what they are 
these days ... the speed increase clearly matters more, as of now.  For 
example, when I compiled gnuchess on the Sun 4/260, it was about 30% smaller
than the binary produced under the DEC 3100.   Interestingly 
despite the more advanced compilers present with the DEC, it took slightly more
time to compile.  But to run it was another story.  The DEC was noticeably
faster.  I did not (g)profile it though, and can't be precise. 

RISC seems to be somewhat superior, given the current technological and 
economic constraints.  It seems a bit shaky though. 

	Raja.

P.S.  Will the 68040 be pin compatiable with its predecessors?  I thought 
it ought to be, but some articles have said it wasn't?  Is there any 
manual or anything technical available at present for the 68040? 
Apart from swiping technical secrets from Motorola, that is. :)

raja@{soda,ocf,athena}.berkeley.edu | root@athena.berkeley.edu | laba-3en@web
	Programmer Analyst I, S & P Dept, UC Berkeley. 
_____________________________________________________________________________
Seeing the basketball team - the New York Knicks, on TV brings a smile to my 
lips, for in Brit English, "knicks" are equivalent to "panties". :)
-----------------------------------------------------------------------------