Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!pioneer!lamaster
From: lamaster@pioneer.UUCP
Newsgroups: comp.arch
Subject: Re: Anyone for memory management on the AM29000?
Message-ID: <1355@ames.UUCP>
Date: Thu, 23-Apr-87 14:10:52 EST
Article-I.D.: ames.1355
Posted: Thu Apr 23 14:10:52 1987
Date-Received: Sat, 25-Apr-87 05:31:42 EST
References: <67@bernina.UUCP> <16336@amdcad.AMD.COM>
Sender: usenet@ames.UUCP
Reply-To: lamaster@ames-pioneer.arpa (Hugh LaMaster)
Distribution: world
Organization: NASA Ames Research Center, Moffett Field, Calif.
Lines: 46
Keywords: AM29000, memory management, TLB

In article <16336@amdcad.AMD.COM> bcase@amdcad.UUCP (Brian Case) writes:
>In article <67@bernina.UUCP> tve@ethz.UUCP (Th. von Eicken) writes:
>>When reading the data sheet I noticed that the TLB entries
>>don not have any "page used" flag nor any "page modified"
>>flag.

:

>Yeah, questions about the "missing" page referenced and modified bits
>in the TLB are always among the first to be asked when people are
>presented with the Am29000.  The deal is:  these bits don't belong in
>TLB entries, they belong either in the page tables themselves or in
>the physical page map (note that for inverted page tables, these
>structures are (or can be) the same thing).  The VAX is brain-damaged

:

>
>But this is not the right way to do it anyway.  The right way is to
>have a small RAM-based table in the memory controller keep track of
>page modification:  there is very little overhead and the information
>is maintained on a per-physical-page basis, just as it should be.
>Also, it is probably the best way for multiprocessor systems.
>
:

This may not be the best way to handle it if the architecture supports
multiple page sizes (and even multiple simultaneous page sizes), because the
page size in effect is not (easily) "known" by the memory controller.  

Even with an architecture-fixed page size, you have decreased the complexity
of the processor/TLB at the expense of the memory controller, which is OK for
a multi-chip/board CPU, but probably not the best for a microprocessor
(consider the history of MC68xxx memory management).


  Hugh LaMaster, m/s 233-9,  UUCP {seismo,topaz,lll-crg,ucbvax}!
  NASA Ames Research Center                ames!pioneer!lamaster
  Moffett Field, CA 94035    ARPA lamaster@ames-pioneer.arpa
  Phone:  (415)694-6117      ARPA lamaster@pioneer.arc.nasa.gov

"In order to promise genuine progress, the acronym RISC should stand 
for REGULAR (not reduced) instruction set computer." - Wirth

("Any opinions expressed herein are solely the responsibility of the
author and do not represent the opinions of NASA or the U.S. Government")