🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #13476

Re: AM29000 memory management (was flame)

#13476
From: Rich Goss
Date: Thu, 23 Apr 1987 23:20
40 lines
2870 bytes
In article <27207@rochester.ARPA> stuart@rochester.ARPA (Stuart Friedberg) 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. Does that mean that the AM29000 memory managenent is even
>> more crippled than on a VAX (which doesn't have a "page used" flag???
>
>A translation lookaside buffer (TLB) is not the same as page tables (PT).
>The TLB serves as a cache of recently used address translations, while
>the PT serves as the source of translation information.  Reference
>(page used) and dirty (page modified) flags belong in the PT.
>
>Stu Friedberg  {seismo, allegra}!rochester!stuart  stuart@cs.rochester.edu

The used and modified flags should be stored along with the page
address in the TLB. Otherwise, the MMU will always have to check
the page table descriptor in main memory to see if these two
flags have been updated on every access to the page being
referenced. For example, a page is read accessed for the first time
and the modify bit is brought into the TLB but not set. If the
page is read accessed again the entry for the page in the TLB is
correct and the page table descriptor in main memory need not be referenced.
However, the next access is a write access to the page. The modify
bit in the TLB is checked, then set, then the MMU should go out
to the page table descriptor in main memory to set the modify bit
in the page table descriptor to agree with the copy of the modify
bit in the TLB. The next access is a write to the page. The TLB
indicates the modify bit has already been set. Therefore the page
table descriptor is correct (the modify bit having already been
set) and no further action is required by the MMU. One can see
that if the modify bit was not cached in the TLB, the MMU would
have to go out to main memory every time the page is referenced 
in order to check and/or set the modify bit.

I do not know how the 29000 MMU operates but the scenario I have
described is used in many demand paged MMU schemes including the
Motorola 68851 PMMU.

-- Rich Goss,
   Motorola Western Regional Field Applications Engineer for 68000 Family
Technical Details
Message-ID: <121@motsj1.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!motsj1!rich
References: <67@bernina.UUCP> <27207@rochester.ARPA>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site motsj1.UUCP
Path: arc1-ca.pugleaf.net!utzoo!mnetor!motsj1!rich
From: rich@motsj1.UUCP (Rich Goss)
Newsgroups: comp.arch
Subject: Re: AM29000 memory management (was flame)
Message-ID: <121@motsj1.UUCP>
Date: Thu, 23-Apr-87 18:20:01 EST
Article-I.D.: motsj1.121
Posted: Thu Apr 23 18:20:01 1987
Date-Received: Sat, 25-Apr-87 05:57:33 EST
References: <67@bernina.UUCP> <27207@rochester.ARPA>
Reply-To: rich@motsj1.UUCP (Rich Goss)
Distribution: world
Organization: /usr/lib/news/organization
Lines: 40