Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!uw-beaver!tektronix!tekcrl!terryl From: terryl@tekcrl.UUCP Newsgroups: comp.sys.nsc.32k Subject: Re: NS32000 Processor Message-ID: <1751@tekcrl.TEK.COM> Date: Tue, 16-Jun-87 14:16:18 EDT Article-I.D.: tekcrl.1751 Posted: Tue Jun 16 14:16:18 1987 Date-Received: Thu, 18-Jun-87 04:31:23 EDT References: <266@udcps1.UUCP> <642@umnd-cs.D.UMN.EDU> <6779@g.ms.uky.csnet> <4399@nsc.nsc.com> Reply-To: terryl@tekcrl.tek.com Organization: Tektronix, Inc., Beaverton, OR. Lines: 71 In article <4399@nsc.nsc.com> tekcrl!tektronix!cae780!amdcad!amd!intelca!oliveb!pyramid!nsc!roger roger@nsc.nsc.com (Roger Thompson) writes: +In article <2295@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes: +> +> My recollection is that the 32000s weren't passed by because IBM +> disapproved but because they could not get their act together to ship +> working chips. Companies and individuals who were used to getting + +When IBM was out searching for a micro, our CPU was stable. What was +the real decider, your guess is as good as mine. But it probably had +more to do with application software being available without +cumbersome AT&T licenses. Ho, boy, I can't really believe this one. Please, Mr Thompson, define "stable". I know for a fact that we (Tektronix) had to do quite a bit of software "workarounds" for bugs in the chip (most notably the memory-manage- ment/TLB hardware). When we discussed these problems with National, the answer was "Oh, of course we know about these problems; they're fixed in the next mask revision" (or words to that effect). If memory serves me correctly (about a 50-50 chance), we were using revision J chips. Naturally, National never told us about these bugs until we discussed it with them. Just my opinion, mind you, but I think Mr. Gilmore was more on the mark than you were. +> functioning chips after 3 revs (less if they weren't alpha test sites) +> gave up after 15 revs without working chips. My personal experience at + +We had *NIX up and running in 1983. The first micro with demand paged +virtual memory. We are working on our third generation MMU and I'm +still waiting for your Mot to come up with one customers like SUN +will use. Well, we had real 4.2 BSD Unix running on a 68010-based system running in late 1983-early 1984, so I'm not going to claim we were the first, but I'm wondering how companies like Sun were able to have one around the time frame you're mentioning (not to mention quite a few vendors who used the multiple 68000 trick to do demand paging; I'd have to say they were the REAL first micros with demand paging). Third generation MMU??? Sounds like you finally have all of the bugs worked out (I know, cheap shot, but as I said before, it was the MMU that was the cause of a lot of headaches for us). Does that also mean the MMU will finally work at the same speed as the processor?? (Another cheap shot, but we couldn't run systems at more than 8 Mhz because of the MMU chip). +> +> I also recall that the "full 32 bit" 32000 chip was only 30% faster +> than the 16-bit version, while Motorola had a part in design that ended +> up 300% to 500% as fast. This tends to support my conclusion that +> it was lack of expertise at chip design and debugging that derailed +> the 32000. + +Yes our 32032 was only 30% faster than the 32016, but there is a good +reason. The 32016 was a 32-bit micro to start with. Not Like the 68000. +The internals of the 32016 and the 32032 are the same. Only the external +data bus is different. The 32332 ( at the same frequencies) is any +where from 50 to 80% faster than the 32032. All three have the same +32 bit internal register architecture and ALU and ALL are 100% +software compatible. Can you say that for all the various Sun systems. Well, I have to concede this one to Mr. Thompson. No, I can't say that the 68000, 68010, and 68020 are 100% software compatible. What I can say is, that if code were to run on a 68000, it could run *unmodified* on a 68010 or a 68020 (I'm talking user code here, not system code). So the various flavors of 680X0 are software compatible UPWARDS (except for one instruction on the 68000). As for the internals of the chips, I'll concede this one to Mr. Thompson, also. Alas, the 68000 and 68010 are really only 16 bits internally, (though the register set is still the same). Terry Laskodi of Tektronix