1 Aug
2004
1 Aug
'04
11:53 a.m.
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).
There are two immediately obvious possibilities (there may
be more, but it's late and I'm off to bed after sending
this :-)). 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. In that case the JMP
would still be executing in physical space and by the
time you hit the target of the jump (8000001E) you
are in system space (which, IIRC< *is* set up).
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 cannot find the details of the instruction fetch buffer (i.e.
its size) but, as I say, it's late and I've not looked extensively.
Hop on over to Manx and type in 78032 - you'll get two
documents that describe the KA630 (you already have the User Guide,
the other one is a preliminary chip guide). If I get the chance
over the next few days, I'll see if I can find out how the
DEMSA/DEMSB worked - that was also based on the 78032 and
I may be able to find out more info from that. The other
78032-based system was the MicroVAX 2000/VAXstation 2000.
Again, the tech manual is available on Manx - at the very least
reading those will keep you busy until I'm awake again :-)
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.
You could extract the important parts of this code
(the table setup and the mmg enabling) and build a
small bootable image that comes up and just HALTs.
Run on your uVII to prove you've got it right and
then run on something later (ideally much later like
an NVAX) to see what happens.
In fact, you might be able to just boot the minimum
code required on a UVAX II and then dump its registers
just to be sure they agree with yours.
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
I looked in the VARM. It is moderately silent about
enabling MMG, but for when disabled it does say the
instruction buffer prefetch should not be allowed within
512 bytes of non-existent memory.
The IB for a UVII seems to be 8 bytes, as is the TB.
The only reference I have for this is DEC technical
Journal N7 (CVAX systems), which, sadly, is not online.
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 kind of detail you need may no longer be in anyones
head. It might have to be determined either by experiment
or by reading the chip microcode. The only person I can
think of who would know where to go to get an answer
would be Bob Supnik.
You should be able to find some KA650 ROM code as
part of SIMH. Given that you probably know the ROM
code pretty well by now (!), how does the KA650
implement this test (if at all). If it's the same,
how does SIMH pass the test?
Antonio
--
---------------
Antonio Carlini arcarlini(a)iee.org