>>If intel had done things rights so that one could use the 36>>bit physical address of its processors, it would be a few more>>years before 64 bit was needed.

> The 32 bit segment32:offset32 addressing already allows for an logical> address space of up to 4 G segments, of 4 GB each. The restriction to a> single segment (in the flat memory model) is an OS convention, not> related to hardware. Other manufacturers can provide more address lines,> and allow access to more physical RAM, than Intel did.

Actually, only 8192 segments, selectors are 16 bits, and then you
subtract the ring and local/global bits.

(snip)

> From the time of NEAR and FAR pointers we should have learned, that> such a distinction is not desireable in source code. It's acceptable> when a compiler allows to mix pointers of different size, when the> details are not reflected in the source code.
(snip)

In 16 bit days, I always ran either large or small, never finding an
advantage to the mixed size medium and compact models.

> [Actually, the entire address space for an x86 process has to fit into> 4GB because the segments are mapped into a 32 bit linear address space> for paging. You can imagine various tricks to map segments in and out> of the linear space, but the performance hit would be awful. -John]

Yes, that is the "if intel had done things right" part that I
mentioned above. Well, it would only be awful it if happened to
often, otherwise it is just bad. Also, I was never sure if any
processors had a segment descriptor cache to speed up reload of
recently referenced segment descriptors. Also, the overhead of
changing the page tables is probably less than the swapping that it
may also be doing at about the same time.

Otherwise, I would have liked to see a mode that bypasses the MMU for
addresses >4GB after doing the segment origin/offset calculation. I
believe the valid bit is still there, so the OS could remap the
addresses as appropriate.