Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!ames!amdahl!sbf10
From: sbf10@uts.amdahl.com (Samuel Fuller)
Newsgroups: comp.arch
Subject: Re: 386/486 Virtual Memory Question...
Message-ID: <744l02C835t601@amdahl.uts.amdahl.com>
Date: 15 Jun 89 19:57:37 GMT
References: <1078200856@andrew.cmu.edu> <48000001@peun39>
Reply-To: sbf10@amdahl.uts.amdahl.com (Samuel Fuller)
Organization: Amdahl Corporation, Sunnyvale CA
Lines: 45

In article <48000001@peun39> bfranke@peun39.UUCP writes:
>
>/* Written  9:36 pm  Jun  6, 1989 by hs0l+@andrew.cmu.edu.UUCP in peun39:comp.arch */
>/* ---------- "386/486 Virtual Memory Question..." ---------- */
>
>The 386 and 486 architectures claim a virtual address space size of
>2^46 bytes.  The virtual address is formed from a 14 bit selector
>and a 32 bit offset.  What does this really mean?  Currently we have
>two interpretations:
>
>	a) This scheme gives us 2^14 different ways to map into
>	   the same 32 bit address space.
>
>	b) This scheme gives us 2^14 independent address spaces
>	   of 2^32 bytes each.  In other words, the virtual memory
>	   scheme consists of as many as 2^14 segments of 2^32
>	   bytes each.
>
>Which one is the correct interpretation?  If (a) is the answer, why was
>it done this way?  If (b) is the answer, how does the processor
>communicate
>the 14 bits of selector information to the memory mapping
>hardware/software?
>
>I think (b) is the correct answer, but after spending a few minutes with
>some Intel literature, I'm more confused than I was when I started.
>Any comments would be appreciated.  Thanks.
>

If they did it right the correct answer should be (a) or (b).  You want
(a) because it allows different processes operating in different address
spaces to still share data.  The kernel can be shared in this way.  (B)
is usually handled by tagging the page table entries in the TLB (MMU) with
the Address Space ID.  The real page number should be a function of both
the ASID and the Virtual Page number.  If the page translator is incapable
of seeing the ASID then it is useless except for flushing virtually
addressed caches.

>Brinkley Sprunt
>Elecetical & Computer Engineering
>Carnegie Mellon University
>sprunt@maxwell.ece.cmu.edu

Sam Fuller / Amdahl System Performance Architecture
amdahl!sbf10