Either
you've made a mistake somewhere and the P0 address *is*
expected to be mapped by the tables or the KA630 (as you suggest)
delays the effect of the MAPEN by one instruction.
It's not the latter. I
tried a small test program: [...]
I tried a program designed to test the "executing out of a prefetch
buffer" theory. It has a stream of sixteen "incl r4"s in physical
memory and as many "decl r5"s at the same addresses in virtual memory,
following an mtpr to enable VM, branched to with an REI to avoid issues
with prefetch on entry to it.
It turns out that a rael KA630 is left with r4=2 and r5=-12, which says
to me that it did "incl r4" twice, one incl on r5 (opcode from physical
memory, operand from virtual), and 13 "decl r5"s. Since the mtpr is 3
bytes, this fits with executing out of an 8-byte prefetch buffer - and
indeed, my simulator with an 8-byte buffer produces the same results.
It appears to interact interestingly with alignment. If I prefix a NOP
to the MTPR, then I see four "incl r4"s and 12 "decl r5"s - the
prefetch buffer gets completely filled from physical memory _following_
the MTPR.
This is sort of interesting, coming up with and then testing theories
of how this works....
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse(a)rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
