KA630 guru?

From: der Mouse <mouse_at_Rodents.Montreal.QC.CA>
Date: Sun Aug 1 17:40:09 2004

> The way VAX/VMS turns on memory management is as follows. (Yours
> looks like it's something else, some console test code, but the same
> principles should apply).

Yes, it's the ROM console code.

> [PHYSICAL] something irrelevant
> [PHYSICAL] MTPR #1, 38
> [P0] JMP _at_#10$
> [SYSTEM] 10$: next-instruction

> Your MTPR executes in physical address mode (mapen off) at address
> 0x0219. The next instruction will be 0x21c, but by them mapping will
> be on, so this must be a virtual address

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 assume that your "v" command is dumping your idea of the system and
> process page tables. Are you sure that you've correctly emulated the
> various registers involved?

I'm reasonably sure, yes. I read over the setup code and simulated it
mentally and came up with the same results.

> Admittedly I'm assuming that whoever coded up this test in the KA630
> console ROM used the same mapping technique as VAX/VMS, but I would
> have thought it a safe assumption

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_at_rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Received on Sun Aug 01 2004 - 17:40:09 BST