Adrian (a.delete@this.acm.org) on January 11, 2020 6:29 am wrote:
> David Hess (davidwhess.delete@this.gmail.com) on January 11, 2020 6:06 am wrote:
> > Brett (ggtgp.delete@this.yahoo.com) on January 10, 2020 9:53 pm wrote:
> > >
> > > Did not realize that the idea of a 64k limited chip was dead and segments would not revive it.
> >
> > How does this differ for the 8086? Wouldn't this objection apply to it also?
> >
>
>
> The same objection was applied to both since the beginning.
>
> However, 8086 was introduced one year earlier, when the only alternative that would not be
> at least one order of magnitude more expensive would have been something like DEC PDP-11.
>
> The method used by DEC PDP-11 to extend the address space from 16 bit to 22 bit was
> much less convenient than the segmentation of 8086 or of 80286, so at introduction
> nobody criticized 8086 for its segmentation, because it was progress anyway.


One thing to remember is that for small programs (by x86 standards, large for 8080), segmentation as implemented in x86-16 provided a substantial increase in memory available for applications, at near zero cost in complexity. Consider that on 8080, the OS, BIOS, memory mapped I/O, the application and its data all had to fit in 64KB. With the trivial x86-16 small model, the application had a full 64KB for code and another 64KB for data. In many applications this doubled the possible amount of code and tripled the size of the dataset being processed.

In many ways it was not until 16-bit protected mode that segmentation became a huge pain. Even there a large part of the problem was the inadequate number of segment registers, the slowness of reloading them, and the loss of a writable CS compared to real mode (which is really the same as the first issue). I'm not suggesting we go back to that, but segmentation in 16-bit protected mode could have been much less painful with some fairly minor changes.