Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!agate!ucbvax!dog.ee.lbl.gov!elf.ee.lbl.gov!torek From: torek@elf.ee.lbl.gov (Chris Torek) Newsgroups: comp.arch Subject: Re: SPARC specs Message-ID: <11858@dog.ee.lbl.gov> Date: 6 Apr 91 04:12:51 GMT References: <2908@wn1.sci.kun.nl> <40941@cup.portal.com> Reply-To: torek@elf.ee.lbl.gov (Chris Torek) Organization: Lawrence Berkeley Laboratory, Berkeley Lines: 26 X-Local-Date: Fri, 5 Apr 91 20:12:51 PST In article <40941@cup.portal.com> mslater@cup.portal.com (Michael Z Slater) writes: >I don't know where to get a reference on Sun's proprietary MMU. As far as I know, you cannot. There are some lovely pictures in the SunOS 4.0 manual sets, and if you read the Sprite source code you can figure out the rest. The MMU is actually quite straightforward: it consists of some number (128 in the SS1, 256 in the SS2) of things Sun call `PMEGs', each of which is just a row of some number (64 in the SS1, probably the same in the SS2) of PTEs. In addition there are some number (8 on the SS1) of `segment tables'. Address translation is done as: vseg = SEGMENT_NUMBER(va); pmeg = segment_table[context_register][vseg]; pte = pmeg_table[pmeg][PAGE_NUMBER(va)]; Here SEGMENT_NUMBER and PAGE_NUMBER are just `pull some bits out of the address'---the top 14 and the middle 6 respectively, on the SS1. Actually the virtual segment number is only 12 bits; the top 3 bits of all virtual addresses must be all 0 or all 1, and the top 2 bits are otherwise ignored. The segment_table and pmeg_table arrays are really just MMU SRAM treated as if it were two separate two-dimensional arrays. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov