Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!uwvax!crystal!mcvoy From: mcvoy@crys.WISC.EDU (Larry McVoy) Newsgroups: comp.arch,comp.sys.nsc.32k,comp.sys.intel,comp.sys.m68k Subject: Re: Question: on-chip or off-chip MMU? Message-ID: <319@crys.WISC.EDU> Date: Sun, 26-Apr-87 15:45:22 EDT Article-I.D.: crys.319 Posted: Sun Apr 26 15:45:22 1987 Date-Received: Sun, 26-Apr-87 23:44:41 EDT References: <5635@shemp.UCLA.EDU> <441@prairie.UUCP> Reply-To: mcvoy@crys.WISC.EDU (Larry McVoy) Organization: U of Wisconsin CS Dept Lines: 84 Xref: mnetor comp.arch:1105 comp.sys.nsc.32k:118 comp.sys.intel:204 comp.sys.m68k:414 In article <441@prairie.UUCP> dan@prairie.UUCP (Daniel M. Frank) writes: (I should note that I'm not really qualified to talk about this, I'm mostly software. But then, so is Dan...) # Short of new technologies such as optical computers and brute-force #methods such as ECL and freon cooling, the only way to speed up a uni- #processor is to increase parallelism. This can be done by pipelining, Whoa there. The ONLY way? I beg to differ. Think about caches for a moment. Most are small, direct mapped, and flushed at context switches. How much performance would be gained by making them larger, separate I&D, full associative, contain process id's, etc. And this bit about optics? Optics? What will that buy you? Sure light travels fast but converting from electrons to photons is a drag. And don't pooh-pooh ECL either. There seems to be a steady supply of new technologies (read about super conductors?). OK, now lets back off a bit. I'm not disagreeing with the statement about parallelism - to a certain extent I agree that a lot can be gained that way. But don't dismiss everything else with one grandiose sweep and expect me to buy it. It's not anywhere close to as simple as you make it sound. # Anyway, the more parallism you want, the more integrated your memory #management hardware has to be with the CPU. If you put it off-chip, #you'll need more pins, and the propagation delays may slow down your #overall cycle time. Not necessarily. Again, remember the value of a nice big smart cache. #at critical times? I claim that the 80x86 series does just that (whether [Flame++ ] The 80x86 series is a load of upwardly compatible garbage and the whole world knows it. I doubt there's a CS or ECE person anywhere that can honestly say they like this architecture. If they do, they should go back to school. Go look at the instruction sets before you flame me. The word "orthogonal" does not exist in the Intel vocabulary. The word "hack" does. [Flame-- ] #> Question 2 : if there is enough space on the chip, would #>everybody put the MMU on-chip? # # I suppose so. If there was enough space (and they could cool it!), #they'd try to put EVERYTHING on the chip. Also not quite true. Large chips are a drag. They're a drag to lay out, a drag to manufacture, a drag to cool (as you noted), etc. What you really want to do is put everything that's in the "main loop" on chip, leave everything else off chip. For example: suppose you look at a Vax and realize that the good old polynomial evaluator instruction isn't used very much. Why not use that chip space for cache and do the poly func in software or in a slave processor? Take the 801 philosophy of having to justify every instruction/feature, whatever on the chip. #> Question 3 : if there is only enough room for either a cache #>or a MMU, which one will prevail? # # My knee-jerk response is: it is so hard to really integrate an external #MMU with a pipelined processor, that you'll win by putting the MMU and a #small cache on chip, and putting a larger cache off-chip. I hear the two #level cache worked out pretty well in the Microvax. It did? I guess you never had more than 1 active job on your uVax, huh? Compare a uVax with 3 users to a 680xx with 3 users. I know where I want to work. --------- I guess that I really want to say this: Don't throw out flip answers to hard problems. I *know* that I have a lot to learn in this area and I try to be especially careful because of it. If you are going to advocate parallelism, don't do so without noting the difficulty of writing parallel code. If you're going to dismiss advances in technology, don't do so without proposing something better. -- Larry McVoy mcvoy@rsch.wisc.edu or uwvax!mcvoy "What a wonderful world it is that has girls in it!"