KA630 guru?

Yes, it's the ROM console code. Yes, that's a nice theory. That's how I would do it and that's how NetBSD does it; I'm not surprised to hear that's how VMS does it. But it is not what I am seeing. Recall I had 00000219 mtpr $1,$38 0000021c jmp (r0) 0000021e nop but the page tables are set up such that P0 address 21c is not valid (the P0 PTE for it is no-access not-valid). However, r0 contains an address, 8000001e, which is mapped to physical address 21e. Thus, I infer that the "jmp (r0)" is somehow supposed to get executed *even though* P0 space is set up such that the jmp does not appear at the place PC points after the MTPR - that place does not exist (there is no virtual mapping for it). Since this code does in fact run on a real KA630, the hardware obviously differs from the simulation. (The code is the KA630 ROM code, so there is nothing inherently wrong with its doing things that depend on its running on a KA630; it doesn't have to care about portability to other VAXen.) I've gone over the page tables and the code that sets them up enough that something like prefetching has become the more plausible possibility. I'm reasonably sure, yes. I read over the setup code and simulated it mentally and came up with the same results. So would I. I went over things in some detail before I convinced myself that it actually is a false assumption, that the code really is depending on something KA630-specific that lets that jmp (r0) get executed even though it looks unmapped. As an experiment, I added instruction-stream prefetching to my simulator. Now it cruises right past that point, executing the jmp out of the prefetch buffer - and falls over later, on something that again looks as though it's expecting to execute out of a prefetch buffer: 20044585: movab 0x2004458d,10(r10) 2004458a: <unrecognized ff ff> 2004458c: nop 2004458d: mtpr $0,$38 ; MAPEN 20044590: jmp *$20044600 20044596: halt In the simulator, when it hits the force-a-trap at 2004458a (which is at that point running in system virtual space at 8000038a), it traps to 8000038c - apparently the previous movab sets up an SCB vector. Then it tries to turn off MAPEN while still running in system virtual space - and the prefetch buffer I gave it (64 bits) isn't big enough to include the entirety of the jmp that follows. Now, it could be that I just haven't given it a big enough prefetch buffer. But I hesitate to just enlarge the prefetch buffer without some reason to be confident that that's really the correct fix. I also really would be more comfortable knowing exactly what events should cause me to flush prefetch (REI is documented to, but, for example, does the trap caused by the ffff opcode do so?) and how prefetching interacts with alignment. I've also wondered if perhaps changing MAPEN is actually delayed by one instruction. This is another thing that could cause the code I see to work, and it wouldn't upset the turning-on-mapping technique you describe. It would, however, break code that expects setting MAPEN to amount from a branch from physical space to virtual space when they _aren't_ mapped to the same place, which according to the VARM I have is perfectly reasonable code. Hence my asking about people who know the KA630 in detail. Most of these things are things I can test on a real KA630 with suitably contrived test code, but things like prefetch have a tendency to work in funky ways that are often hard to discover with black-box testing. /~\ 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