Re: Does the KA630 have a TB?

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

On 2023-09-24 18:39, Mouse wrote:
> > > 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.)

Fair enough.

> > > 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*!)

Sent that separately. But 512 entries, evenly split between S and P.

Well. With no bitslice, would you have been better at identifying the 
CPU through a bunch of 74xx TTL logic. After all, that's what you find 
in the 11/780.

> > 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.

Latent bugs can sometimes hang around for a really long time, for sure.

> > 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.

So maybe there is actually some bugs in your code after all. ;-)

> > > 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"....

But you don't even know it's for the bus adapter until you've gone 
through the PTE translation anyway.

While once you've done the translation, it's obvious.

> 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.)

Hmm. Yeah, if an access would succeed for a mode which you actually 
should not permit, then you're on thin ice.

> > > 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 4K page is a bit more recent. Back when this was messed around with, 
NetBSD used a 1K page size on VAX.

  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