Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!henry From: henry@utzoo.UUCP (Henry Spencer) Newsgroups: net.arch,net.micro.68k,net.micro.16k Subject: Re: 16k vs 68k vs 432 Message-ID: <3463@utzoo.UUCP> Date: Wed, 11-Jan-84 14:37:55 EST Article-I.D.: utzoo.3463 Posted: Wed Jan 11 14:37:55 1984 Date-Received: Wed, 11-Jan-84 14:37:55 EST References: <524@nsc.UUCP>, <220@dual.UUCP> <3451@utzoo.UUCP>, <247@kobold.UUCP> Organization: U of Toronto Zoology Lines: 26 Tom Teixeira asks: 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. Given that the 16032 MMU is *not* just a combinatorial logic block, but a complex state machine which sits on the cpu bus, manipulates it in non-trivial ways, and does its own memory accesses using that same bus, and given that the same set of wires carries virtual addresses from the cpu, physical addresses from the MMU, and data to and from both, pulling devious tricks involving reshuffling the bits strikes me as asking for trouble. I would recommend against it. It's true that simply using N "real" pages as a single "logical" page involves extra overhead in space and time, but if these overheads are significant then I would suspect the software of doing something stupid. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry