I'm looking for an MFPR example

[mikes...@gmail.com]

Hi all,

I've been playing with OPENVMS on SIMH, and am wondering what the MFPR instruction does during the ROM boot code?

The MACRO manual explanation is not very helpful

I thought from reading it, that it would (in "non (VM) mode, as I assume the SIMH vax is on "power on"), behave just like a MOVL instruction ?

But apparently / obviously, these are not the same thing : (when I EXAMINE 2000)

MOVL #2000,R1
MFPR #2A,0(R1)
MOVL #2A,0(R1)

"If the processor is in virtual machine (VM) mode, and the virtual machine is
in kernel mode, then a VM-emulation trap is taken. The destination operand
is replaced by the contents of the processor register specified by procreg. The
procreg operand is a longword that contains the processor register number.
Execution may have register-speci?c side effects.

<rant on> (for manual writers)

USE EXAMPLES !!
</rant off>

thx

Mike

[mstram]

This is TOO Funny !

Mike
"The answer to life the universe and everything = 42"

Cause I found my answer to what this "mysterious" code (to me at the time) is:

$2A .. or 0x2A of course being = .... :)

MFPR #2A,44(R1)

KA660 CPU Module Technical Manual
http://deathrow.vistech.net/~cvisors/dec94mds/ka660tm1.pdf

3.9.6 The Hardware Halt Procedure
The Hardware Halt Procedure is the mechanism by which the hardware assists the firmware in emulating a processor halt. The hardware Halt Procedure saves the current value of the PC in IPR 42 (SAVPC), and the current value of the PSL, MAPEN<0>, a halt code and VALID bit in IPR 43 (SAVPSL). The formats for (SAVPC) and (SAVPSL) are shown in Figure 3–9 and Figure 3–10 respectively.

[Bob Koehler]

In article <2730fbea-7d3e-4525...@googlegroups.com>, mikes...@gmail.com writes:
=> Hi all,

>
> I've been playing with OPENVMS on SIMH, and am wondering what the MFPR instruction does during the ROM boot code?
>
> The MACRO manual explanation is not very helpful

IFF you're talking VAX instructions:

MFPR: move from priviledged register. That register is quite
possibly model specific, so it will depend on what model VAX is being
emulated. There is a much longer list for an 11/780 than for a
Micro-VAX II.

This lets priviledged code get model specific data into normal
registers or memory.

There is, of course, a reverse instruction: MTPR.

Generally these should not be seen outside model specific kernel
code.

[Johnny Billquist]

On 2012-07-23 07:42, mikes...@gmail.com wrote:
> Hi all,
>
> I've been playing with OPENVMS on SIMH, and am wondering what the MFPR instruction does during the ROM boot code?
>
> The MACRO manual explanation is not very helpful
>
> I thought from reading it, that it would (in "non (VM) mode, as I assume the SIMH vax is on "power on"), behave just like a MOVL instruction ?
>
> But apparently / obviously, these are not the same thing : (when I EXAMINE 2000)

Of course it's not the same thing!
MFPR - Move From Processor Register. How could that ever be the same as
a MOVL???

> MOVL #2000,R1
> MFPR #2A,0(R1)

So, move from processor register 2A to wherever R1 points to.

Note: *internal* processor register.
Read the processor manual for that specific CPU to find out what
processor internal registers there are. :-)

> MOVL #2A,0(R1)
>
> "If the processor is in virtual machine (VM) mode, and the virtual machine is
> in kernel mode, then a VM-emulation trap is taken. The destination operand
> is replaced by the contents of the processor register specified by procreg. The
> procreg operand is a longword that contains the processor register number.
> Execution may have register-speci?c side effects.

Eh... Why are you reading about virtual machine behavior? That is so
outside the world here that it's totally not relevant, helpful or
useful... :-)

> <rant on> (for manual writers)
>
> USE EXAMPLES !!
> </rant off>

Well, if anyone had actually ever implemented virtual machines on VAXen,
then maybe some examples might have come about.

For now, read the manual for the specific processor you are writing the
code for, to find more specific information about the internal processor
registers, since lots of this stuff is processor specific.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Bob Eager]

On Mon, 23 Jul 2012 22:56:03 +0200, Johnny Billquist wrote:

> Well, if anyone had actually ever implemented virtual machines on VAXen,
> then maybe some examples might have come about.

Every process in VMS runs in a virtual machine.

Unless, of course, you mean the very specific, limited kind of virtual
machine that mimics the real one.

--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org

*lightning protection* - a w_tom conductor

[Johnny Billquist]

On 2012-07-23 23:00, Bob Eager wrote:
> On Mon, 23 Jul 2012 22:56:03 +0200, Johnny Billquist wrote:
>
>> Well, if anyone had actually ever implemented virtual machines on VAXen,
>> then maybe some examples might have come about.
>
> Every process in VMS runs in a virtual machine.
>
> Unless, of course, you mean the very specific, limited kind of virtual
> machine that mimics the real one.

I do indeed mean the very specific kind, which is what he was quoting
from in the manual...

The kind of virtual machine that could (in theory) boot VMS on it.

The "virtual" machine that every process runs under is not that complete
a virtual machine. Things like MFPR are not expected to work on those
virtual machines... As far as a virtual VAX goes, it is extremely
limited, only giving you your own virtual memory, and a CPU which
implements all the non-privileged instructions, as well as magic
incantations that in fact request services from an operating system.
Very non-bare-metal behavior...

[Bob Eager]

On Tue, 24 Jul 2012 10:23:34 +0200, Johnny Billquist wrote:

> On 2012-07-23 23:00, Bob Eager wrote:
>> On Mon, 23 Jul 2012 22:56:03 +0200, Johnny Billquist wrote:
>>
>>> Well, if anyone had actually ever implemented virtual machines on
>>> VAXen, then maybe some examples might have come about.
>>
>> Every process in VMS runs in a virtual machine.
>>
>> Unless, of course, you mean the very specific, limited kind of virtual
>> machine that mimics the real one.
>
> I do indeed mean the very specific kind, which is what he was quoting
> from in the manual...
>
> The kind of virtual machine that could (in theory) boot VMS on it.
>
> The "virtual" machine that every process runs under is not that complete
> a virtual machine. Things like MFPR are not expected to work on those
> virtual machines... As far as a virtual VAX goes, it is extremely
> limited, only giving you your own virtual memory, and a CPU which
> implements all the non-privileged instructions, as well as magic
> incantations that in fact request services from an operating system.
> Very non-bare-metal behavior...

My point was not it's not avirtual VAX, and nor should it be.

But sorry, I missed the earlier reference....!

I have too many students on my OS courses who get this wrong! (and yes, I
do still talk about VMS a bit...)

[Bob Koehler]

In article <a75sar...@mid.individual.net>, Bob Eager <news...@eager.cx> writes:
>
> Every process in VMS runs in a virtual machine.

VMS has always been "Virtual Memory", but that does not a virtual
machine make.

Of course, if you're trying to translate between VAX and x86
terminology, you may come up with misleading concepts.

[Bob Eager]

On Tue, 24 Jul 2012 15:00:52 -0600, Bob Koehler wrote:

> In article <a75sar...@mid.individual.net>, Bob Eager
> <news...@eager.cx> writes:
>>
>> Every process in VMS runs in a virtual machine.
>
> VMS has always been "Virtual Memory", but that does not a virtual
> machine make.

I stand by what I said. The virtual machine provided is one that has
virtual memory, virtual I/O, etc. It's just different to any real
machine...the I/O is done via the CMKRNL instructions, etc., but it's
still I/O.

Some people call that kind of virtual machine a 'process virtual machine'
rather than a 'system virtual machine' but it is still a virtual machine
nonetheless.

[Johnny Billquist]

On 2012-07-24 11:45, Bob Eager wrote:

> My point was not it's not avirtual VAX, and nor should it be.
>
> But sorry, I missed the earlier reference....!

Not sure exactly what you said here. But I guess in a way, both are
virtual VAXen, in that a user process runs in virtual memory, with a
subset of the full VAX architecture. I know that some might call that a
virtual machine, although I don't think I'd use that terminology.

But anyway, I was indeed referring to a virtual machine of the full
kind, which looks like the actual hardware to a level where you boot the
OS on it.

> I have too many students on my OS courses who get this wrong! (and yes, I
> do still talk about VMS a bit...)

I'd be surprised if even 5% of students got it right. Understanding on
this level is not something I found very common when I was teaching at
my University.

Nice to hear VMS still being mentioned. Back in my day (well, this is
about 20 years ago), we had a course on compilers, where students had to
implement a compiler for a silly, primitive "high" level language, and
which produced assembler on the backend. The assembly code had an
uncanny similarity to PDP-10 assembly, for some funny reason... By that
time, the PDP-10 was sinking into obscurity, and the students didn't
know what the backend was, but they produced output from the compiler
for it anyway. :-)
(And then we had a test platform, which executed the assembly code, and
made it possible to verify that the code produced by their compiler
actually worked...)

Johnny