Re: Does the KA630 have a TB?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Ragge added some TBIA calls in April 2000; see rev 1.78 of the VAX
>> pmap.c.
> Speaking of that, 1.85 is also fun...

Indeed!  As I mentioned (in text I've cut, below), when I incorporated
them, I took 1.78 as modifed by 1.85.  (But, in my implementation, TBIA
doesn't care what the value you're moving into it is anyway.)

>> Certainly.  But how many different models has 1.4T/vax been tested
>> on?  Personally, don't think I've ever tried it on anything but a
>> uVAX2, which Antonio Carlini said has a _tiny_ TB (8 bytes).
> Well.  The 11/750 was what Ragge was initially using, and was the
> first system I also used, back at 0.9.

What does it have for a TB?  (I recall, back when decommissioning
a...730, I think it was, back in the day, we went looking for the CPU.
We didn't realize it was a bitslice architecture; the only thing we
could recognize as a CPU was a Z80, presumably part of the console
tape.  We half-seriously decided it was a Z80 running a VAX emulator -
it was so *slow*!)

> But that version had definitely been run on other hardware than just
> uVAX2.  And it sounds amazing that the problem would have been mostly
> unnoticed...

I've not infrequently been surprised by how long latent bugs have gone
unnoticed.  A lot of things don't even close to take advantage of all
the liberty their spec actually permits.  Consider how few VAXen
actually go off the deep end, instead of just taking a machine check or
some such, when running into UNDEFINED situations.  By the book, they'd
be perfectly justified in switching to executing 6502 instructions or
some such.

> But then again, Ragge did throw in those additional flushes at some
> point for a reason.

Indeed!

>> I've now modified my NetBSD/1.4T enough that it appears to work with
>> the large TB.  [...]
> Cool.  Sounds like that was the problem, then.

Yes...but, now, I find that it fails when I remove the TB logging code
(which I'd like to remove for performance's sake; it introduces some
relatively complex operations into a very heavily used codepath).  I've
so far been unable to see what it does that makes any difference; I'll
have to dig deeper.

>> Translation buffer statistics:
>> Hits 792967524 misses 3419573 (99.5706%), enters 3089291
>> Level 1: 6/4096 (0.146484%)
>> Level 2: 72/12288 (0.585938%)
>> Clears: all 27910, one 0

>> [...] my TB doesn't cache anything that doesn't point to main
>> memory.
> Why not cache entries outside main memory, by the way?

The main motivation for adding the TB was that I want to experiment
with JITting the code to native machine code.  But VAX code typically
accesses memory relatively heavily, even aside from the instruction
stream, so I want memory access to be relatively simple.  With a TB
with a decent hit rate, I would consider it reasonable to compile
memory accesses into code that punts to the slow path on a TB miss.
But then I need to somehow handle PTEs that map device registers and
the like; those will have to take the slow path anyway, so the simple
thing is to just exclude them from the TB altogether.  This would
permit the native machine code for a memory access to be relatively
streamlined.  "Make the common case fast"....

Hm, that makes me realize my TB has no permissions.  I need to fix 
that; as it stands, a TB hit succeeds regardless of PSL<CM>.  (It does
pay attention to modifiy bits, to be sure.)

>> I find it interesting that this NetBSD doesn't use TBIS at all.
> Agreed.  Seems like it would potentially be clever to just do TBIS
> when you update one page.

True.  It may be relevant that NetBSD/vax, 1.4T at least, uses 4K pages
in the getpagesize() sense; mapping what the VM subsystem considers a
single page requires what the hardware sees as eight PTEs.  This helps
reduce VM subsystem overhead, certainly, but it could also have
deterred people from using TBIS.  And, to be fair, I'd have to measure
the comparative speed of eight TBISes (either in a loop or unrolled)
versus a single TBIA (and the concomitant refills of unrelated
entries).

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B