dillon@CORY.BERKELEY.EDU.UUCP (04/05/87)
>The neat thing about the '386 is that it can run UNIX, unlike the 68020. >With the 68020 you have to put an MMU in your system. However, hardware >guys at companies that make affordable computers seem to have this thing >against putting MMUs in. With the '386, no silly hardware person can >leave out the MMU. An MMU a UNIX system doesn't make. It takes a lot more than a mere MMU to make a *real* UNIX system smooth. When your talking 'real' systems, your talking enough complexity that having the MMU internal or external doesn't really make a difference. Don't get me wrong... I'm all for having the MMU on chip, but frankly I think it will only make a difference in smaller systems. In terms of the dreaded 68020/80386 wars, and if I took a neutral stance on the speed issue, it all comes down to a preference of which instruction set one likes best. I personally (and this is why I'm on this newsgroup) like Motorola. Not just for their 680X0 series, but for their single chip microcomputers as well. The 68705 for instance. And as far as quality goes, Motorola is right up there with HP. -Matt
tim@ism780c.UUCP (04/06/87)
In article <8704050506.AA25220@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
< An MMU a UNIX system doesn't make. It takes a lot more than a mere
< MMU to make a *real* UNIX system smooth. When your talking 'real' systems,
< your talking enough complexity that having the MMU internal or external
< doesn't really make a difference.
My point was not that internal MMUs are in some way better than external
MMUs ( they aren't ). My point was that when the MMU is not on the same
chip as the CPU, it often gets left off. An internal MMU will beat the
pants off of a nonexistent MMU!
With a '386, the hardware guys would have to to do a lot of extra work to
stop me from running Unix. With a 680xx, they have to do some extra work
to let me to run Unix.
--
Tim Smith "And if you want to be me, be me
uucp: sdcrdcf!ism780c!tim And if you want to be you, be you
Compuserve: 72257,3706 'Cause there's a million things to do
Delphi or GEnie: mnementh You know that there are"root@sbcs.UUCP (04/07/87)
> your talking enough complexity that having the MMU internal or external > doesn't really make a difference. Don't get me wrong... I'm all for having MMU done internally vs externally DOES make a difference - it is fairly hard to pipeline an external MMU so that translation/protection doesn't slow your basic memory cycle time by 25-50%. Yes, clever RAS/CAS'ing (ala Sun/Becholsteim) helps, but I want my translation done on CPU silicon where the system designer can't "forget" the MMU, come up with non-standard architectures (read custom port of Unix for EVERY machine), make hardware tradeoffs (e.g. pagesize) in the absence of software expertise, etc.. > In terms of the dreaded 68020/80386 wars, and if I took a > neutral stance on the speed issue, it all comes down to a preference > of which instruction set one likes best. I personally (and this is why My personal loyalty is solely for the fastest (75%), cheapest (5%), most standard (20%) silicon at any given point. Instruction sets are nice to talk about, but lets face it, they are really only for compilers and compiler writers to worry over. I hack assembly language (it doesn't matter which or how elegant after all these years) on the 20% of the programs I write which can't do what I need in C (perhaps 0.1 % of the overall code of these programs). Anyways, with the advent of RISC, the days of polynomial instructions, offset@(reg, reg:size) addressing modes are numbered. The whole point of this is merely: Give me a fast 32 bit programming environment with translation/protection, and I'll be happy.. With the 386, 29000 (almost), 68030 (almost) out, it doesn't matter whether the cover on the chip carrier reads "Motorola", "Intel", "AMD", etc. Rick Spanbauer SUNY/Stony Brook