Date   : Fri, 12 Aug 2011 22:50:09 +0100
From   : philb@... (Phil Blundell)
Subject: Risc PC (Was 'Minitel in France')

On Fri, 2011-08-12 at 22:10 +0100, Theo Markettos wrote:
> One possible reason is that a machine might have 1MB of physical RAM and
> 32MB of logical address space.
> 
> AIUI the L2P tables are direct indexed from the physical side (ie page 47 in
> physical RAM stores its mapping in entry 47 in the L2P table, the page size
> varying with the amount of physical RAM fitted).  If you had the same
> structure the other way around (ie one mapping entry for each logical page)
> most of the entries would be wasted as there would be no physical RAM there. 
> So with 128 direct indexed entries pages would be 256KB, which would be
> rather painful.  Particularly on 512KB machines!

Yes, that's true.  If you key the mapping on logical rather than
physical addresses then you don't need to use CAMs any more, which ought
to mean that you could afford rather more slots since the implementation
is simpler.  But you might be right that the cost of the extra RAM bits
to cover the whole address range would still be too much.

If you wanted to support 32MB virtual space in 8k pages then that's,
obviously, 4096 pages in total or 12 bits of address.  Assuming that you
didn't ever want to support more than 16MB of physical RAM, you only
need 11 bits of data for each slot.  So that's a total of 4096*11=45056
bits of RAM to hold the page mappings, which doesn't seem like it would
have been obviously prohibitive even in 1990.  If you were prepared to
accept 32k pages then you could divide that by four.

I guess the physically-keyed approach does have the nice property that
the page size automatically scales with the amount of physical RAM,
irrespective of the size of the logical area. 

p.