Paul Koning suggested we ask Bob Supnik, and he explained it. On 2023-03-23 19:39, Johnny Billquist wrote:
On 2023-03-23 19:20, Mouse wrote:Yeah. I wonder what's behind it. [...]You could also ask why P0LR<26:24> are ignored. Same story.!! I missed that. Thank you for pointing it out. If anything, that one is even stranger. The sign bit, that at least could make a tiny, if twisted, bit of sense. But the 0x07000000 bits? That's just bizarre. The only other place I see bits 26:24 of anything mentioned is that they're the ASTLVL bits in the PSL. But I have trouble imaginingDEC caring about software that confuses PSL with P0LR, quite aside from all the other reasons I have trouble seeing that as relevant.I have no clue about that, and find it incredibly strange.Agreed! (And my VAX emulator has a couple of bugs for me to fix.):-DIf I ever come up with any answer about those bits, I'll let you know. But for now, they are just really strange. But somehow DEC thought it important enough to define them in the VARM.
Actually, you were right about the ASTLVL. And it's the same with P1LR<31>. And it's in VARM, but I didn't even think about it.
If you look in chapter 6 or VARM, it contains the process context block. And in there, those bits are actually used. The ones in P0LR are for the ASTLVL, while the bit in P1LR is for performance monitor enable.
And to make things easier to implement, it is required that those bits be ignored when writing P0LR and P1LR, so that the process context block can be loaded without any additional processing of those fields.
Mystery solved. :-)Thanks to Paul for suggesting I ask Bob, and thanks to Bob for explaining it.
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