Path: utzoo!attcan!uunet!ficc!cliff
From: cliff@ficc.uu.net (cliff click)
Newsgroups: comp.arch
Subject: Re: 80486 vs. 68040 code size [really: how many regs]
Summary: Spout ing falsehoods
Message-ID: <4228@ficc.uu.net>
Date: 18 May 89 13:21:47 GMT
References: <950@aber-cs.UUCP> <25651@amdcad.AMD.COM>
Distribution: eunet,world
Organization: Ferranti International Controls
Lines: 29

In article <25651@amdcad.AMD.COM>, tim@crackle.amd.com (Tim Olson) writes:
> In article <950@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
> | there is the little matter of a few FACTs, called CRISP, NOVIX and
> | TRANSPUTER, 
> You speak of FACTS, then spout FALSEHOODS.  Rather than guessing, why
> don't you really study the performance of the processors you mention as
> compared to current RISC processors.

Yes, how about some FACTS on these chips?  How about some facts on 
the 32bit version of the NOVIX, Phil Koopman's WISC chip, and 
Johns Hopkins Labs (nuts! I can't remember the name) stack oriented 
chip.  All of these chips were faster (more MIPS per Mhz) than the 
currently available chips (680xx, 80x86) in '87 - using fairly old 
technology.  How fast might they be if they had a sustained development 
effort on the order required to produce the 29000 and the 88000?

Did the big name chip developers miss something here?  Why didn't any
of them develop a dual (4?) stack chip, zero (ok 1 or 2) addressing 
modes, harvard architecure (3 data paths), 16 (or 32) intructions that 
were essentially the chips micro-code (instruction bits fed directly 
into the control lines on chip, very little decode time).  All of these 
chips could do a call/branch in 1 cycle, return in 0 cycles, and passed 
parameters lived on the stack with everything else.  Usually stacks 
were cached on chip with overflow to memory.

-- 
Cliff Click, Software Contractor at Large
Business: uunet.uu.net!ficc!cliff, cliff@ficc.uu.net, +1 713 274 5368 (w).
Disclaimer: lost in the vortices of nilspace...       +1 713 568 3460 (h).