🚀 go-pugleaf

>Can anyone tell me where I can find info on SPARC 2 Page Memory Addressing
>and how it differs from the SPARC 1 chip.

Well, it would help if you told us what the "SPARC 1 chip" was.  There
are no SPARC processor chips with names such as "SPARC 1" and "SPARC 2".

If by "Page Memory Addressing" you're referring to the MMU, the
SPARCstation 1 has, I think, a gate array as its MMU, and the
SPARCstation 2 probably does as well.  The main difference between their
MMUs is that the SS2 has more contexts (16 rather than 8) and more pmegs
(256 rather than 128). 

Both of them are "Sun MMU"s, in that they work the same way the MMUs
work on most other Sun models.  Here follows a description of the "Sun
MMU", and of the "SPARC Reference MMU" as used on the 6xxMP, SS10, and
various other machines; it should probably go into the FAQ:

> Would some kind netperson please explain (by email if possible) how 32-bit
> virtual addresses are translated into physical addresses using the SPARC
> "reference MMU," whatever that is?

The SPARC Reference MMU is a specification for the way memory management
units should work on most SPARC chipsets done in the recent past,
present, and at least short-term future.  Various recent SPARC chips
include SPARC Reference MMUs; for example, the Cypress 7C604 and 7C605
MMUs (the 605 is what was originally used in the SPARCserver 600MP
machines), and the Texas Instruments TMS390Z50 "Viking" chip.

> I understand there is a two-level
> translation scheme, using a segment map and a page map. There's also
> something called a "context register." I'm clueless beyond this point.

The only part of that which is in the SPARC Reference MMU is the context
register.  The SPARC Reference MMU uses a *three*-level translation
scheme, and doesn't use static RAM segment and page maps; instead, the
page tables are in main memory.

The memory management unit you described there is the so-called "Sun
MMU".  That isn't a SPARC-specific MMU; it's the style of MMU Sun used
in their very first machines, which didn't have SPARCs because SPARC
didn't exist yet.

> What I'd like to know specifically is:
> 
> 1. What is the context register? Is it something that establishes how a
>    particular process's virtual addresses are translated to physical?
> 
> 2. How does the two-level translation take place?
> 
> 3. What is the segment map? The page map? What is a page map entry group
>    (PMEG) and why are page map entries grouped?
> 
> 4. How are the 32 bits of a virtual address mapped to 32 bits of physical
>    address? (E.g., the low-order 12 bits is the offset in a page, the next
>    5 bits are the page number...that sort of thing).

Yup, you're definitely thinking of the Sun MMU, not the SPARC Reference
MMU; PMEGs are Sun-MMU concepts.

The Sun MMU comes in both two-level and three-level forms; the
SPARCsystem 4xx (4/490, 4/470) machines had three-level MMUs, and the
other Suns with Sun MMUs (all Suns except for:

	the Sun386i, which used the 386's on-chip MMU;

	the Sun-3/80 and Sun-3/4xx, which used the 68030's on-chip MMU;
	
	the SPARCserver 6xxMP and SPARCstation/SPARCserver 10, which use
	either Cypress or TI chips with a SPARC Reference MMU)

all had two-level MMUs.

The way the two-level Sun MMU works is that there is a "context
register", a bank of static RAM called the "segment map", and another
bank of static RAM called the "page map".

The value in the context register, and the uppermost N bits of the
virtual address (which may, or may not, be a 32-bit virtual address; the
Sun-2s had 68010's, which only supported 24-bit virtual addresses, and
even on most of the Sun-3's, not all the virtual address bits were used
- - even on some SPARC machines, some of the middle bits of the virtual
address aren't used), are concatenated and used as an index into the
"segment map".  Out of that lookup comes an M-bit number.

Those M bits, and the next P bits of the virtual address, are used as an
index into the "page map".  Out of that lookup comes a page map entry,
which is similar to a page table entry on MMUs with in-memory page
tables.  The page map entry contains:

	a bit to specify if it's valid or not;

	protection bits that specify whether the page is writable, and
	whether it's accessible only to kernel-mode code or to
	kernel-mode and user-mode code;

	some other stuff (for example, on machines with caches, it
	contains a bit to indicate if references to that virtual address
	are cachable);

	and Q bits of physical address.

Assuming the page table entry is valid, and that it grants permission
for the type of access being done, the Q bits of physical address and
the bottommost K bits of virtual address (where 2^K is the page size -
2K bytes on a Sun-2, 8K bytes on a Sun-3, 4K bytes on the "small"
SPARCstations, 8K bytes on the other SPARC machines) are glued together
to make the full physical address.

On the machines with 3-level Sun MMU's, there's a "region map", and the
context number and topmost virtual address bits are an index into that
map.  The output of that map, and the next few bits, are an index into
the segment map; the output of that map, and the next few bits, are an
index into the page map.

The output of the segment map refers to a group of page map entries; the
bits of the virtual address that are glued onto the segment map output
select one of the entries in that group.  That group is a page map entry
group, or PMEG.  They're grouped in that fashion because, if you want to
set up a mapping for a given virtual address, you have to set up that
entire group of entries to refer to other virtual addresses in a range
of virtual addresses around that virtual address; the reason why you
have to do that should be obvious from the description of how the map
works.

The way the virtual address bits are broken up depends on the particular
machine.  For example, on machines with 4K pages, the lower 12 bits are
the offset in a page; on machines with 8K pages, the lower 13 bits are
the offset in a page; on machines with 2K pages, the lower 11 bits are
the offset in a page.  The size of a pmeg is also different on different
machines.

The idea behind the "context register" is that only a limited number of
mappings can fit in the static RAM.  The system could, whenever it
switched address spaces, load up mappings for the new address space;
however, that would be required every time the system switched to
running a new process, and that would be somewhat expensive.  Instead,
the MMU allows mappings for *multiple* processes to be loaded into the
MMU; the value in the context register specifies which process's
mappings are in effect at any given time.

Thus, to switch to the address space of a process that has a context in
the MMU, the system can load up a new value into the context register;
to switch to the address space of a process that *doesn't* have a
context in the MMU, the system would have to arrange that that process's
mappings be loaded into the MMU.  So if you have N contexts in the MMU,
and one of them is reserved for the kernel (which is the way SunOS does
it), if you have N-1 or fewer processes competing for the CPU, the
system runs faster than if you have N or more, as it doesn't have to
load and unload mappings as frequently.

The Sun386i used the 80386's on-chip MMU; the 3/80 and 3/4xx used the
68030's on-chip MMU; and the 6xxMP and SPARCstation 10 use chips with a
"SPARC Reference MMU".

Those MMUs are all different from the Sun MMU, in that they *don't* have
banks of static RAM that act as "region map", "segment map", or "page
map".  Instead, there are level 1, level 2, and, on MMU's with 3-level
maps, level 3 page tables in memory.  They act in a fashion somewhat
similar to the static RAM maps.

The 386's MMU has no context register, and neither does the 68030's MMU;
instead, to switch to a new process's address space, a register is
loaded that points to the top-level table for the mapping (I don't think
it's a simple level-1 page table on the 386, given that it can support
48-bit segmented address spaces; however, UNIX systems tend not to use
the segmentation, and give processes 32-bit unsegmented address spaces).

The SPARC Reference MMU, however, *does* have a context register.  The
context register value is used as an index into the context table, which
is a table in memory; the entry for the current context in that table is
a page table pointer that points to a level-1 page table in memory.  The
top 8 bits of the virtual address are used as an index into the level-1
page table; the entry in that table can either be:

	1) an invalid mapping, which causes a trap;

	2) a page table entry, which says that the 16 megabytes of
	   virtual address specified by those 8 bits are mapped to a
	   given 16-megabyte range of physical addresses;

	3) a page table pointer, which says that there's a level 2 page
	   table in memory at an address specified by the page table
	   pointer, and that the next 6 bits of virtual address have to
	   be used to look up an entry in that table.

The level 2 page table can have an invalid mapping, a page table entry,
or a page table pointer.  The page table entry maps 256 kilobytes, and
the page table pointer points to a level 3 page table in memory.

The level 3 page table can have an invalid mapping or a page table
entry; the page table entry points to a 4K byte page in memory.

> 1. On the paper describing the Cypress chipset, the section on the Cypress
>    CY7C604 says, "The CMU translates 32-bit virtual addresses from the
>    processor into 36-bit physical addresses." 36-bit? Is that a misprint?

Nope.  The physical addresses really are 36 bits; the Mbus is a 36-bit
bus.  For example, on one Mbus-based machine under development:

	if the upper 4 bits are 0, it's physical memory;

	if they're 0xC, 0xD, or 0xE, it's the VME bus;

	if they're 0xE, it's the Sbus

	if they're 0xF, it's various on-board I/O chips.

> 2. On MMUs with a translation lookaside buffer (TLB) like the Cypress, I
>    assume the TLB's purpose is to cache translations so that the multi-level
>    lookup can be avoided?

Yup.  Most, if not all, MMUs with in-memory page tables have a TLB.

And some MMU's have nothing *but* a TLB; the MMU on MIPS chips, some if
not all HP-PA chips, and I think the DEC 21064 Alpha chip, is basically
just a TLB.  If a mapping isn't found in the TLB, the processor traps,
and the trap handler is a small bit of code that walks the page table
and loads an entry in the TLB (needless to say, that code is in a region
of the address space that can be accessed *without* using the TLB).

> 3. Some of the SPARC IU architecture papers mention an Alternate Space
>    address; the IU places an alternate space identifier on some output pins
>    while it accesses the bus. Are these used by the MMU to distinguish between
>    kernel mode and user mode accesses?

Well, that's one thing for which they're used.  The IU puts 4 bits of
Address Space Identifier out on *all* memory references.  ASI 0x8 is for
user-mode instruction fetches, 0x9 is for kernel-mode instruction
fetches, 0xA is for user-mode data fetches, and 0xB is for kernel-mode
data fetches.  That gets fed to the MMU, and it uses them to figure out
whether it's a kernel-mode or user-mode fetch.

There are also "load alternate" and "store alternate" instructions;
those are privileged (kernel-mode-only) instructions that specify a
particular ASI value to put out for the reference.  For example, with
the SPARC Reference MMU, ASI 0x3 is typically used for flushing the TLB
or probing the MMU to see the page table entry for a virtual address,
and ASI 0x4 is used to read and set the internal registers in the MMU.