Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!microsoft!philba
From: philba@microsoft.UUCP (Phil Barrett)
Newsgroups: comp.arch
Subject: Re: looking for >32-bit address space
Message-ID: <1226@microsoft.UUCP>
Date: 4 Apr 89 19:00:38 GMT
References: <1032@myrias.UUCP> <1220@microsoft.UUCP>
Reply-To: philba@microsoft.UUCP (Phil Barrett)
Organization: Microsoft Corp., Redmond WA
Lines: 28

In article <1220@microsoft.UUCP> donh@microsoft.UUCP (Don Hacherl) writes:
>In article <1032@myrias.UUCP> cmt@myrias.UUCP (Chris Thomson) writes:
>>Are there any micros or chipsets out there that support an address space
>>larger than 32 bits?  The current trend in micros seems to be toward 64-bit
>>data paths but only 32-bit address paths.
>
>The Intel 386 supports a 46-bit virtual address space (32 bits of
>offset + 16 bits of selector - 2 bits of selector protection),
>although the linear and physical address spaces are only 32 bits.  I
>know of no OS that supports this, though (does Intel have a 386 iRMX?).
>Flat 32-bit address spaces are very popular these days, and no one
>wants to buck the trend. 
>

Intel does have an RMX 386 but last I looked, it doesn't support > 4Gb
address space.  

I've spent some time looking at how one would go about taking advantage of
this feature of the 386 and it's pretty messy.  Demand paging under demand
segmentation isn't that hard but the big problem is that there is only one
active page directory and it only (gee, what a limitation) addresses 4Gb. You
would need to virtualize the page table/dir to get beyond 4Gb instantaneous
addressability for a single process. Its possible to do but I think the 
performance wouldn't be that good.  Consider a string move between 2 virtual
4 Gb segments. 

I think the 64TeraByte virtual address space of the 386 is more smoke than
anything else.