Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site kobold.UUCP
Path: utzoo!linus!decvax!genrad!grkermit!masscomp!kobold!tjt
From: tjt@kobold.UUCP
Newsgroups: net.arch,net.micro.68k,net.micro.16k
Subject: Re: 16k vs 68k vs 432
Message-ID: <247@kobold.UUCP>
Date: Tue, 10-Jan-84 13:23:53 EST
Article-I.D.: kobold.247
Posted: Tue Jan 10 13:23:53 1984
Date-Received: Wed, 11-Jan-84 08:31:26 EST
References: <524@nsc.UUCP>, <220@dual.UUCP> <3451@utzoo.UUCP>
Organization: Masscomp, Westford, MA
Lines: 26

The problem with compensating for a small page size by pretending the
page size with bigger (as is done in 4BSD for the VAX and National's
4.xBSD port) is that page tables take up N times as much space, and the
inner loops for setting up page tables run N times slower.

On the other hand, a large page size causes you to lose more storage to
fragmentation.

Actually, I had heard that the real reason the VAX used 512-byte pages
was because the unibus disks used 512-byte blocks.  Actually, the
physical disk block sizes are less important than the logical file
system block size.

Anyway, does anyone know if it is possible to use the NS 16032 MMU with
some additional logic to look at function codes and fool it into using
a larger page size directly? i.e. the MMU would normally ignore the
bottom 9 bits of the address and only look at the page number.  You can
feed whatever bits you want in as the page number.  Similarly, you can
take the translated page number to high order bits.  By definition, the
low order bits (page offset) of the address aren't changed by the MMU.
However, if the MMU does not find the right page table entry in its
on-chip cache, it will fetch it from memory, in which case the memory
system needs to use exactly the address generated by the MMU.
-- 
	Tom Teixeira,  Massachusetts Computer Corporation.  Westford MA
	...!{ihnp4,harpo,decvax,ucbcad,tektronix}!masscomp!tjt   (617) 692-6200