🚀 go-pugleaf

In article <1990Jan24.174315.13698@ux1.cso.uiuc.edu>, mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes:
> In article <21990004@hpvcfs1.HP.COM> johne@hpvcfs1.HP.COM (John Eaton) writes:
> >In order to understand some of the limitations of the PC you must remember
> >how the 8086 came to be. Intel was on a roll with the 4004/8008/8080 and
> >decided to go all out and design a micro that really had some POWER. It
> >was to be something that could challenge the minis and become the chip
> >of the 80's. I believe it was originally called the "432". But they still
> >needed to keep business coming in the door until this wonder chip was ready
> >so they decided to do a quick and dirty enhancement of the 8080. This was the
> >8086. It's only purpose was to keep the 8080 family alive until Intel could
> >deliver its real processor. Its hard to fault the designers for any design
> >decisions that were appropriate for it's expected lifespan.
> >
> 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.

The main problem with the first suggestion is that unless there are other
changes in the machine code, it makes writing position-independent routines
more difficult.  Things like .COM files exploit the fact that you don't
need to do any fixups to run a .COM file at any segment address (if the 
prorgram follows some fairly simple and obvious rules).  However, they
could have gotten much of the benefit of the 8086 segments without *quite*
so many of the drawbacks by making the segment values multiples of 64 or
256 bytes rather than multiples of 16.  This would not waste a great deal
of memory due to fragmentation, and would allow a _much_ larger address
space.   The main problem is that at the time, the memory lost due to
fragmentation probably looked bigger than it does today.

Probably they should have done something along this line, possibly
making all the memory address instructions relative or having both
relative and absolute forms.  But if you aren't careful you might
end up designing a 68000, which wouldn't do now would it? :-)

The second suggestion is a pretty good idea, but it would have complicated
the design (there's no need to have anything like counters or adders for
dealing with the segment registers, except as necessary for the address
generation hardware).

						Bruce C. Wright