Re: NetBSD in SIMH vax with 512 MB RAM

[Johnny Billquist <bqt%softjar.se@localhost>]

On 2023-03-23 18:00, Mouse wrote:
> > > > Let's first of all agree that a page table size larger than 2^21
> > > > entries is pointless.
> > > Well, worse than pointless; it could completely break operation.
> >  From a hardware point of view?  No.  It would just waste memory.  So
> > - pointless. Remember, the system page table is just a bunch of ram
> > in your physical memory.
>
> Well, depends on what you mean by "a page table size".  If you mean
> "data structure in kernel space", then, yes.  But if you mean "value
> set in the SLR", I disagree; see below.

Well, my point was really about the actual page table being larger. 
Nothing about SLR at that point.
So yeah, the data structure. Having it larger is just pointless. Which 
eventually leads us to the point that there is no reason to ever set SLR 
to more than 2000000. So we shouldn't.

> > > But...
> > > > The MMU will pick which page table to use based on the top two bits
> > > > of the virtual address.  [...]
> > > If the P0LR, P1LR, and SLR values are within range, yes.  If not, it
> > > might not [...]
> > If you read 4.4.3 of the VARM, it clearly states that the first check
> > on the virtual address is on the top 2 bits, and any check after that
> > is based on those two bits.
>
> Yes.
>
> But, as soon as you store a value outside the 0..200000 range in the
> SLR, that is irrelevant.  At that point the hardware can do almost
> anything without violating the VARM.  (The "almost" is because there is
> one thing it is not permitted to do, that being to hang, to, in the
> words of the VARM, "reach an unhalted state from which there is no
> transition to a normal state in which the processor executes
> instructions".  It is not clear to me whether that "transition" can
> include things like "external reset button pressed" or, to be even more
> extreme, "power turned off and back on".)

Well. Yes, for anything related to the SLR, anything can happen if the 
value is outside that range. Agreed. But I would assume it is anything 
that actually involves the SLR, and not just random anything in the machine.

However, trying to address something above E000 0000 does not involve 
the SLR in the first place. This is also clearly defined in the VARM.

> > In practice, you could implement this in various ways, but clearly
> > the VARM states that if you try to address 0xc000 0000, you *must*
> > get a length violation, no matter what SLR might be.
>
> ...as long as nothing has been done that produces UNDEFINED behaviour.
> Setting SLR greater than 200000 is such a thing.

Setting the SLR to something large has undefined behavior. Agreed. 
However, that does not allow you to do undefined things in other places 
that have a clearly defined behavior that is not at all connected to the 
SLR.

Or else you could just say that as soon as anything is set to an 
undefined behavior, the whole machine is just undefined everywhere, and 
you can start interpreting instructions as 6502 opcodes.

I guess in a sense, that would be within the specs, but hardly a useful 
interpretation. It would mean that recovery would be impossible as soon 
as anything undefined was done.

> > > [...], except for an odd note that "Writing P1LR<31> has no effect.
> > > The bit always reads as 0.".
> > That's a weird one...???
>
> Yeah.  I wonder what's behind it.  That text is in 4.6.2, "P1 Region",
> on page 4-26.  It sounds a little bit like permission for large
> negative values, but I can't see why there would be any need for that.

You could also ask why P0LR<26:24> are ignored. Same story. Any data 
written to those bits are ignored, and always reads back as zero.
I have no clue about that, and find it incredibly strange.

  Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol