25 Oct
2010
25 Oct
'10
10:47 a.m.
On 10/25/10 00:46, Brad Parker <brad at heeltoe.com> wrote:
I have a low-level pdp-11 question...
I'm confused about writing to the PSW on cpu's which support user&
supervisor mode. My
read of the docs is that in user mode you should not be able to write
the "mode" bits of the PSW.
(or, perhaps more accurately, you should not be able to*clear* any mode
bits from user space)
I have a little diagnostic which doesn't work as I though it should
under simh and I thought I'd
ask what others think...
Basically, simh allows code running in "user mode" to write the PSW even
when (I claim) it
should not. I have not tried this on a real 11/44 or 11/34 yet, but I
can/will.
Should simh allow this? In the test blow the "clr @#PSW" is successful
when run
on simh and I think it should basically be a nop...
(which begs another question - should it be a nop? or a exception?)
A side question might be "the psw is not protected from writes, except
by using
the mmu" - is this true on all models? or just some? The 11/40 manual
implies
that it*is* protected. But 11/73 docs seem to say the opposite and
imply using the mmu.
diagnostic follows:
.TITLE test17
.ASECT
PSW=177776 ;processor status word
.=34
.word 200
.word 0007
.=200
mov #200, r5 ;we should be in kernel mode here
rti
.=500
clr @#PSW ;kernel mode
mov #500,sp ;sp=500 in kernel mode
mov #140000,@#PSW ;user mode
mov #700,sp ;sp=700 in user mode
trap 377 ;should move us to kernel mode
nop
clr @#PSW ;back to kernel mode
nop
halt
The PSW, when regarded as a memory location, is not protected at all.
How could it be?
The PSW is protected, when we talk about the MFPS/MTPS instructions, as
well as the RETI/RETN.
For an operating system, you normally protect the whole I/O page from
user access, since not only the PSW is in there, but all kind of stuff
that you do not want user programs to get access to.
Data in the I/O page follows the same rules as any other memory
essentially. If you have write access to it, you can write to those
locations. The underlying device responding to those writes have no idea
what the PSW is, and cannot enforce any protection. The special case of
the PSW itself is perhaps "odd" since it actually do know what the PSW
is (obviously) but it still follows the same rules as all other devices.
Johnny