Article View: comp.sys.ibm.pc
Article #9261Re: 640K limit
From: David Hinds
Date: Wed, 24 Jan 1990 23:01
Date: Wed, 24 Jan 1990 23:01
52 lines
3824 bytes
3824 bytes
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
Technical Details
Message-ID:
<8539@portia.Stanford.EDU>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ogicse!decwrl!shelby!portia!dhindsReferences:
<4668.25aed7f2@uwovax.uwo.ca> <21990004@hpvcfs1.HP.COM> <1990Jan24.174315.13698@ux1.cso.uiuc.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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 <dhinds@Portia.stanford.edu> Organization: Stanford University Lines: 52