Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ogicse!decwrl!shelby!portia!dhinds From: dhinds@portia.Stanford.EDU (David Hinds) Newsgroups: comp.sys.ibm.pc Subject: Re: 640K limit Summary: The 8086 wasn't so badly designed! Message-ID: <8539@portia.Stanford.EDU> Date: 24 Jan 90 23:01:26 GMT References: <4668.25aed7f2@uwovax.uwo.ca> <21990004@hpvcfs1.HP.COM> <1990Jan24.174315.13698@ux1.cso.uiuc.edu> Sender: David Hinds Organization: Stanford University Lines: 52 In article <1990Jan24.174315.13698@ux1.cso.uiuc.edu>, mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: > Yes, but why did they have to botch it? One tiny, simple change > in it, that would not increase (it probably would DECREASE) the > gate count, and it would have been MUCH better: make the segment > registers a simple extension of the address - that is, the > 8086 would have used only 4 bits of the segment registers, > but the 80286 would use 8 and the 80386 all 16. > > A second change to the 8086, that would have added two instructions, > would have been to add "add carry to segment register" and > "subtract carry from segment register" instructions. > > IT would still get flamed for segments, but at least the 80286 > would have been able to run 8086 code directly. > This is wrong. Segments are not such a bad way of increasing the amount of addressable memory. Remember, the 8086 does 16-bit arithmetic, and segments were what made 1M of address space possible. Having segment registers just be the top address lines would have been a disasterous mess. It would force things to be aligned to 64K boundaries to fully exploit the range of a 16-bit address offset. Note that the same basic segmentation concept is preserved even in the 80386's protected mode. Yes, the meaning of the value loaded in a segment register is different, but the philosophy is the same. A segment can start at a nearly arbitrary location in memory, paragraph-aligned for the 8086 or byte-aligned on the 80386, and all address references are segment-relative. The advantage of the 80386 is that the range of offsets is bigger - not that the segmentation concept has been removed. As the meaning of a segment register value is different in the protected modes of the 80286 and 80386, there is no way that Intel could have made the 8086 segment registers transparently compatible. I find all these complaints about the 640K barrier to be very circular. Given the design of the 8086, it seems to be a reasonable choice to allocate memory above 640K for system use. Is there any more reasonable place to put the stuff? IBM had sufficient foresight to allocate enough space for system use, that we are only now running out of room. Remember that the "below 640K crunch" is also an "above 640K crunch". I don't think we can be critical of Intel for making the 8086 "so" limited. Ten years (or was it longer) ago when the chip came out, 1 meg of memory was more than a lot of mainframes had, and more than a PC user dreamed of. The level of machine language compatibility between the 8086 and the protected modes of the '286 and '386 is extremely high for things that don't muck around with segment registers. I think the lack of a suitable operating system for the 80386 is a much more fitting target for complaints. And before anyone says "just use Unix", I don't think the present state of Unix ports is such that they are appropriate for the general PC community. Most people don't want the responsibilities of a system administrator just to keep a PC running. And most people also don't want to spend as much on their operating system as they paid for their computer. - David Hinds dhinds@portia.stanford.edu