Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site spar.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!decwrl!spar!freeman From: freeman@spar.UUCP (Jay Freeman) Newsgroups: net.arch Subject: Re: I like segmented architectures Message-ID: <291@spar.UUCP> Date: Wed, 5-Jun-85 03:55:13 EDT Article-I.D.: spar.291 Posted: Wed Jun 5 03:55:13 1985 Date-Received: Mon, 10-Jun-85 01:00:24 EDT References: <276@spar.UUCP> <5653@utzoo.UUCP> Reply-To: freeman@max.UUCP (Jay Freeman) Organization: Schlumberger Palo Alto Research, CA Lines: 91 [oh glorious line-eater, accept this humble sacrifice] How delightful to see a posting that generates more light than heat! (Henry Spencer's, cited below). Pray allow me to continue my perverse Devil's advocacy of brand I segmented architectures ... In article <5653@utzoo.UUCP>,henry@utzoo.UUCP (Henry Spencer) writes: (responding to an earlier posting of mine) >> I suggest that these features are sufficiently useful, that the >> allocation of silicon and the provision of software to support them, >> should not be dismissed as a trivial and obvious mistake: True >> fans of the 68XXX and 32XXX would clearly not wish to win merely by >> exploiting public ignorance of their adversary's strengths. > >Unfortunately for Intel, these are also strengths of the 68XXX and the >32XXX; it's just a little less conspicuous, because it's more transparent. >Herewith an explanation, in the context of the 32XXX (because I'm not too >familiar with the 1000 different 68XXX MMUs). >... [and so on] Our exhange of comments appears to establish that the X86 and 32XXX have generally comparable memory-management and task-switching capabilities, implemented by different approaches to hardware -- segment registers and so forth on-chip in the case of the Intel stuff, more conventional memory-management in a separate chip in the case of the 32XXX. It would be a shame to let a nice argument die for so inadequate a reason as mutual agreement, so let me pick up on a few points: >> Given the >> expense in silicon real estate to do this in parallel, there is no >> speed penalty at all. > >The 32XXX does slow down when you turn on the MMU, but this translation >overhead is *always* present in the Intel cpus (although Intel has done >a better job of minimizing it, assisted by the on-chip location of their >MMU). The only speed penalty on the 32XXX that is specifically the >result of the MMU chip being separate (as opposed to being the result of >separate decisions on bus management etc.) is the small overhead involved >in bringing signals on and off chips. I don't think it is quite that simple: On-chip data-flow is typically notably faster than inter-chip information transfer, both because of more parallelism and because the designer presumably has better control of what's going on there. Certainly the 286 comes up to bus bandwidth with no difficulty -- when doing memory-to-memory string moves a word at a time, the rate of data flow is one byte per CPU clock (strictly, one two-byte memory-to-memory move every two CPU clocks) (NB: That would have been "every four CPU clocks" for the 8086 -- the 286 really does use fewer clocks.) Thus if Intel is in fact presently shipping 12 MHz 286's (late ads so suggest), the corresponding data transmission rate is 12 Mbytes / second, notwithstanding all the segment checking. How does that compare with the speed of the latest 32XXX's, with MMU engaged? The fact that the 286 can achieve this speed suggests that the segment stuff is really very fast. (And it sure would be nice if that bus were 32 bits, wouldn't it?) (Buried in here is a quite complicated issue pertaining to chip speed, having to do with what is bottlenecking the clock: If it should turn out that that were the segment-checking stuff, then one would have to look very carefully at the tradeoff obtained by omitting this feature and obtaining higher speed overall. But I don't know, of course.) (And I trust we all agree that neither the X86 nor the 32XXX nor the 68XXX are RISC machines; and that the issue of RISC versus more traditional architectures is worthy of a whole separate tempest in its very own teapot.) > ... managed automatically by the hardware, >rather than requiring the programmer (or his compiler) to do the job >itself by explicitly loading segment registers. This is a two-edged sword: Segment registers look just like address registers, and allow richer addressing modes when explicitly manipulated. That is, an X86 address is obtained by adding the contents of up to three registers, plus an "immediate" offset. (Lots of people will say that fancy addressing modes are a pain, and they may be right -- here is the RISC issue again.) And if you don't like the segment registers, surely it's not too much trouble to set them once and forget them. (I have indeed admitted, in my first posting, that 64K segments are too small.) By the way, where are the 68XXX fans? Surely the Motorola chip isn't so bad that no one can find a defense for it. :-) Why, with all those pins it makes a great brush for stuffed animals and plush furniture. :-) Real programmers can't SPELL quiche!! :-) -- Jay Reynolds Freeman (Schlumberger Palo Alto Research)(canonical disclaimer)