Path: utzoo!attcan!uunet!sco!seanf
From: seanf@sco.COM (Sean Fagan)
Newsgroups: comp.arch
Subject: Re: 68020 vs. 68030 speed (was Re: 80486 vs. 68040 code size)
Message-ID: <2760@scolex.sco.COM>
Date: 22 May 89 06:24:42 GMT
References: <4229@ficc.uu.net> <6924@cbmvax.UUCP>
Reply-To: seanf@scolex.UUCP (Sean Fagan)
Distribution: eunet,world
Organization: The Santa Cruz Operation, Inc.
Lines: 48

In article <6924@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes:
>in article <4229@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) says:
>> Probably. I've never had the opportunity to use or even see a 32000-based
>> machine, unfortunately.

I have.  Real fun to play with.  Problems described below.

>I think the problem was the first 32ks (actually called 16ks until some deal
>set up with TI made National change the name to 32k) were kinda wimpy as
>compared to the existing 680x0s at the time.  I looked at them briefly,
>way back when, but I don't recall whether it was the performance at a
>given clock speed or the lack of high enough clock speeds.  The nicest
>part of the first 32ks was the instruction set, which was the same across
>all parts, like the 68000, only more so, and more orthogonal.  

I think the real problem was that it took NS *many* revisions to get a
working CPU.  The system I mentioned up above was a 16032, Revision R,
running at 6 MHz (*slow*). (Note:  it was still about half as fast as
our 3b5, but, then, the 3b5 didn't have paging.)  Despite being the 18th or
so revision of the CPU, there were still quite a few bugs associated with it
and the MMU (seperate chip).  In fact, the Unix kernel we had (4.1BSD based)
had code in it that would determine whether the mmu was bad, and, if so, not
use the "features" that caused it to manifest.  Also, if I remember
correctly, the compiler wouldn't generate a certain addressing mode (double
indirect something, I think; the "most complicated" mode on it) because it
was known to be buggy.  Oh, and a friend says that the ENTRY instruction is
wrong; something about it pushing the frame pointer at the wrong time (if
what he says is true, then I can believe it).  Unfortunately, this was a
"feature," documented and everything, so it still exists in the '532.

I *really* like the series.  Nice instruction set (even if it wasn't
designed by Seymour Cray 8-)), well integrated sub-processors (FPU, MMU,
etc.), nice addressing modes, etc.  When NS got the CPU's working, I was
expecting them to take off, but, apparantly, Motorola beat them to the
punch.  Too bad.

(Also, I would like to note that NS is, as far as I know, the only processor
maker who managed to ship their *co*processors bug-free before the processor
did.  IBM, for example, use the NS fpu in the RT for a while.)

Remember, I have *no* personal affiliation with *any* chip maker, and I
don't mean to slight National Semiconductor.  I like their stuff, and I am
(still) trying to get a cheap ICM for myself.

-- 
Sean Eric Fagan  |    "[Space] is not for the timid."
seanf@sco.UUCP   |             -- Q (John deLancie), "Star Trek: TNG"
(408) 458-1422   | Any opinions expressed are my own, not my employers'.