Re: rtVAX300 .. adding an CPU Type..

[Holm Tiffe <holm%freibergnet.de@localhost>]

Anders Magnusson wrote:

> On 01/04/2013 09:29 PM, Jason Thorpe wrote:
> >On Jan 4, 2013, at 2:39 AM, Mouse <mouse%Rodents-Montreal.ORG@localhost> 
> >wrote:
> >
> >>>>As some of you already know I'm fiddeling around with an ISA Board
> >>>>in a PC that has an rtVAX 300 CPU on it.
> >>>The primary difference between the rtVAX and normal VAX is that the 
> >>>rtVAX re$
> >>It's not totally clear to me, yet, whether the rtVAX 300 works this way
> >>or whether it has the normal VAX P0 and P1 setup.  The ROM code makes
> >>me moderately sure that either it's a normal VAX in this respect or it
> >>ignores the high bit of the P0BR - all ROM code that sets P0BR sets the
> >>high bit except for one case which I suspect is an expected-to-fail
> >>test.
> >>
> >>>This means all the process page tables have to be physically contiguous 
> >>>(as $
> >>Perhaps proper KA620 (and other machines with that style of P0/P1 page
> >>tables) support would mean building a pmap that migrates pages in an
> >>attempt to maintain a large physically contiguous free block?
> >...or uses a single page table and zeroes / lazy-copies from 
> >process-specific tables as needed.  (OMG that would be so slow... but easy 
> >:-)
> >
> Actually, after last pmap rewrite on vax (10-15 years ago? :-)  it works 
> in a way similar to that.
> 
> The usrptmap is preallocated in kernel space and can at most
> handle (currently) processes of size 1GB.
> Space for processes are allocated out of this submap, and since
> most processes are much much smaller than 1GB this is normally not a 
> problem,
> but if suddenly a process need lot of memory it will unmap some idle 
> processes
> and use their space in the usrpt.
> 
> This was very effective as it seems since:
> - It's not often processes needs much memory.
> - It do not need so much preallocated memory on the kernel page table.
> 
> 1GB of user virtual memory takes 8MB kernel virtual memory
> which in turn takes 64K physical memory.  If the indirection is missing
> then the page tables would take 8MB physical memory instead,
> or less, if the usrpt is shrunk in size.
> 
> -- Ragge
> 

Besides you guys talking here from things I know almost nothing of,
I've looked closer at the two Memory SIMMs that are on that rtVAX300 Board.
Thera re 2 Modules each of them with 18 pcs. MT4C4004 Memory Chips 1Mx4bit.
So the entire memory is 4MB + 16bit Parity.

Is that enough to run a NetBSD kernel over NFS?

Roger wrote it already, here again from the Manual: (pg 3-11(82))

3.1.8 Memory Management

The rtVAX 300 implements the full VAX memory management as defined in the
VAX Architecture Reference Manual. System space addresses are virtually
mapped trogh single-level page tables, and process space addresses are
virtually mapped trough 2-level page tables. Refer to the VAX Architecture
Reference Manual for description of the virtual to physical address
translation process and the format for VAX page table entries (PTEs).

3.1.8.1. Translation Buffer

To reduce the overhead associated with translating virtual addresses to
physical addresses, thertVAX 300 processor employs a 28-entry, fully
associative translation buffer for caching VAX PTEs in modified form. Each
entry can store a modified PTE for translating virtual addresses in either
the
VAX process space or VAX system space. The translation buffer is flushed
whenever memory management is enabled or disabled, for example, by writes
to IPR 56, when any page table base or length registers are modified, for
example by writes to IPRs 8 to 13, and by writing to IPR 57 (TBIA) or IPR
58 (TBIS).

...whatever this means...


Regards,

Holm


-- 
      Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, 
     Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583
  www.tsht.de, info%tsht.de@localhost, Fax +49 3731 74200, Mobil: 0172 8790 741