> 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_at_iee.org
Received on Sun Aug 01 2004 - 18:53:24 BST