MXPY PDP-11 instructions
81 views
Skip to first unread message
Anton L.
Jun 18, 2024, 9:36:33 PMJun 18
to [PiDP-11]
Hi all,
I'm trying to figure out how these Move To/From Previous Instruction/Data instructions work... And I'm having a bit of a hard time understanding them.
Handbook does not specify any restrictions about using these instructions, which is weird.
The only discussion I found was this (PDP-11/40 Handbook):
5.7.2 Data
Data is transferred between modes by two instructions: Move From Pre·
vious Instruction space (MFPI) and Move To Previous Instruction space
(MTPI). The instructions are fully described in Chapter 4. However, it
should be noted that these instructions have been designed to allow data
transfers to be under the control of the inner mode (Kernel) program
and not the outer, thus providing protection of an inner program from an
outer.
Data is transferred between modes by two instructions: Move From Pre·
vious Instruction space (MFPI) and Move To Previous Instruction space
(MTPI). The instructions are fully described in Chapter 4. However, it
should be noted that these instructions have been designed to allow data
transfers to be under the control of the inner mode (Kernel) program
and not the outer, thus providing protection of an inner program from an
outer.
Thus, it kind-a suggests that I can't move data from say, user space, to kernel space.
But when you look at the description for the instructions, there seem to be no restrictions mentioned.
So does that mean that
.TITLE MTPD
.MCALL EXIT$S
START: CLR R1
MOV #256.,R2
1$:
CLR -(SP)
MTPD (R1)+
SOB R2, 1$
EXIT$S
.END START
.MCALL EXIT$S
START: CLR R1
MOV #256.,R2
1$:
CLR -(SP)
MTPD (R1)+
SOB R2, 1$
EXIT$S
.END START
would clear interrupt vectors, assuming the previous CPU mode was "0"(kernel), and the interrupt vectors were mapped "natively" at VA 0 in kernel?
I find it hard to believe. And if it is not supposed to work, what's going to happen?
Compiled and run the above under RSX and observed no harm to the system and no visible side-effects. So, what actually happened in there? Any clues / help please?
Thanks,
Anton
Johnny Billquist
Jun 18, 2024, 9:40:56 PMJun 18
to pid...@googlegroups.com
It's simple. Previous space is taken from the PSW. And in user level you
cannot change that part of PSW, so it's basically not possible to use it
to circumvent memory protection. But it's useful in the kernel when you
want to read data from the user process.
Johnny
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/b21fd329-f794-4548-9bd8-596e42a07196n%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/b21fd329-f794-4548-9bd8-596e42a07196n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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
cannot change that part of PSW, so it's basically not possible to use it
to circumvent memory protection. But it's useful in the kernel when you
want to read data from the user process.
Johnny
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/b21fd329-f794-4548-9bd8-596e42a07196n%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/b21fd329-f794-4548-9bd8-596e42a07196n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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
Johnny Billquist
Jun 18, 2024, 9:43:31 PMJun 18
to pid...@googlegroups.com
I should perhaps point out that when you are at user level, the previous
mode is normally also set at user level. It's just when you have traps
or interrupts that the previous level gets set up from the current
level, so that the kernel/hardware knows which level it came from.
Johnny
mode is normally also set at user level. It's just when you have traps
or interrupts that the previous level gets set up from the current
level, so that the kernel/hardware knows which level it came from.
Johnny
Anton L.
Jun 18, 2024, 9:55:27 PMJun 18
to [PiDP-11]
Thanks, Johnny.
I thought when a task starts, the previous mode would be "kernel", because that's what loaded up the program, and then transferred control to it (and that's what would have changed the mode to "user").
Well, I suppose I don't understand how it all orchestrated at the lower level LOL
But then the question again, can you tell me what my code did? ;-)
No crash, no nothing. Quietly exited as if nothing happened.
Johnny Billquist
Jun 18, 2024, 10:17:56 PMJun 18
to pid...@googlegroups.com
You wrote to low bits of memory in your own process. Down there you have
some areas that are sometimes used by some language runtime systems, but
otherwise unused. You might also have some overlay data structures, but
I suspect your program was small and straight forward enough that it was
basically memory with content that noone cared about.
Johnny
> https://groups.google.com/d/msgid/pidp-11/b21fd329-f794-4548-9bd8-596e42a07196n%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/b21fd329-f794-4548-9bd8-596e42a07196n%40googlegroups.com> <https://groups.google.com/d/msgid/pidp-11/b21fd329-f794-4548-9bd8-596e42a07196n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/pidp-11/b21fd329-f794-4548-9bd8-596e42a07196n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
some areas that are sometimes used by some language runtime systems, but
otherwise unused. You might also have some overlay data structures, but
I suspect your program was small and straight forward enough that it was
basically memory with content that noone cared about.
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
>
>
> --
> 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
>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/8a5eeb38-6d6b-43a1-9935-d281e03a0c82n%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/8a5eeb38-6d6b-43a1-9935-d281e03a0c82n%40googlegroups.com?utm_medium=email&utm_source=footer>.
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit
Johnny Billquist
Jun 18, 2024, 10:34:03 PMJun 18
to pid...@googlegroups.com
By the way - under RSX, the loading of the task is not done by the
kernel. It's the responsibility of another task - LDR. But if you have
an inactive task already in memory, then activation is by the kernel,
but then registers and memory content are already defined.
RSX is rather modular, and you could in some sense argue that it's
sortof a microkernel. The kernel itself actually is pretty limited in
what it do, and it depends on various tasks to actually take care of a
lot of things for it to behave like an OS in a way you expect.
There is LDR which is responsible for loading tasks into memory, as well
as for swapping tasks in and out from the swap space.
Then you have TKTN which is responsible for dealing with the termination
of tasks, and possible snapshots of the memory if the task crashed, or
you explicitly ask for a snapshot.
Then you have INS, which is responsible for installing and making tasks
available to the kernel, as well as installing share memory images.
LOA is used to load device drivers.
UNL is used to unload device drivers.
MCD is the command dispatcher for all typed commands by users.
SHF is the memory shuffler, which moves tasks around in memory in order
to defragment physical memory when needed.
RCT is responsible for replacing bad blocks on MSCP disks.
F11ACP is responsible for implementing a file system on disks.
HRC for reconfiguring the hardware related aspects of the system.
And then the list goes on with all kind of more "normal" user programs.
So when you type "RUN FOO", first INS gets invoked to make your program
available to the kernel. Then LDR gets involved in pulling the content
of the task image into actual memory. And that might invoke SHF, if
enough physical memory that is free can't be found. And when your
program finishes, REM gets invoked to remove the task image from the
kernel again, since this isn't a permanent installed task.
But in the end, what you faced was just that previous mode is usermode
for usermode programs. :-)
Johnny
>> >> Handbook does not specify any restrictionsabout using these
kernel. It's the responsibility of another task - LDR. But if you have
an inactive task already in memory, then activation is by the kernel,
but then registers and memory content are already defined.
RSX is rather modular, and you could in some sense argue that it's
sortof a microkernel. The kernel itself actually is pretty limited in
what it do, and it depends on various tasks to actually take care of a
lot of things for it to behave like an OS in a way you expect.
There is LDR which is responsible for loading tasks into memory, as well
as for swapping tasks in and out from the swap space.
Then you have TKTN which is responsible for dealing with the termination
of tasks, and possible snapshots of the memory if the task crashed, or
you explicitly ask for a snapshot.
Then you have INS, which is responsible for installing and making tasks
available to the kernel, as well as installing share memory images.
LOA is used to load device drivers.
UNL is used to unload device drivers.
MCD is the command dispatcher for all typed commands by users.
SHF is the memory shuffler, which moves tasks around in memory in order
to defragment physical memory when needed.
RCT is responsible for replacing bad blocks on MSCP disks.
F11ACP is responsible for implementing a file system on disks.
HRC for reconfiguring the hardware related aspects of the system.
And then the list goes on with all kind of more "normal" user programs.
So when you type "RUN FOO", first INS gets invoked to make your program
available to the kernel. Then LDR gets involved in pulling the content
of the task image into actual memory. And that might invoke SHF, if
enough physical memory that is free can't be found. And when your
program finishes, REM gets invoked to remove the task image from the
kernel again, since this isn't a permanent installed task.
But in the end, what you faced was just that previous mode is usermode
for usermode programs. :-)
Johnny
>> >> instructions, which is weird.
>> >>
>> >> The only discussion I found was this (PDP-11/40 Handbook):
>> >> 5.7.2 Data
>> >> Data is transferred between modes by two instructions: Move From
>> Pre·
>> >> vious Instruction space (MFPI) and Move ToPrevious Instruction
>> >>
>> >> The only discussion I found was this (PDP-11/40 Handbook):
>> >> 5.7.2 Data
>> >> Data is transferred between modes by two instructions: Move From
>> Pre·
>> space
>> >> (MTPI). The instructions are fully described in Chapter 4.
>> However, it
>> >> should be noted that these instructions have been designed to
>> allow data
>> >> transfers to be under the control of the inner mode (Kernel)
>> program
>> >> and not the outer, thus providing protection of an inner program
>> from an
>> >> outer.
>> >>
>> >> Thus, it kind-a suggests that I can't movedata from say, user
>> >> (MTPI). The instructions are fully described in Chapter 4.
>> However, it
>> >> should be noted that these instructions have been designed to
>> allow data
>> >> transfers to be under the control of the inner mode (Kernel)
>> program
>> >> and not the outer, thus providing protection of an inner program
>> from an
>> >> outer.
>> >>
>> space,
>> >> to kernel space.
>> >> But when you look at the description for the instructions, there
>> seem
>> >> to be no restrictions mentioned.
>> >>
>> >> So does that mean that
>> >>
>> >> .TITLE MTPD
>> >> .MCALL EXIT$S
>> >> START: CLR R1
>> >> MOV #256.,R2
>> >> 1$:
>> >> CLR -(SP)
>> >> MTPD (R1)+
>> >> SOB R2, 1$
>> >> EXIT$S
>> >> .END START
>> >>
>> >> would clear interrupt vectors, assuming the previous CPU mode was
>> >> "0"(kernel), and the interrupt vectors were mapped "natively" at
>> VA 0
>> >> in kernel?
>> >>
>> >> I find it hard to believe. And if itis not supposed to work,
>> >> to kernel space.
>> >> But when you look at the description for the instructions, there
>> seem
>> >> to be no restrictions mentioned.
>> >>
>> >> So does that mean that
>> >>
>> >> .TITLE MTPD
>> >> .MCALL EXIT$S
>> >> START: CLR R1
>> >> MOV #256.,R2
>> >> 1$:
>> >> CLR -(SP)
>> >> MTPD (R1)+
>> >> SOB R2, 1$
>> >> EXIT$S
>> >> .END START
>> >>
>> >> would clear interrupt vectors, assuming the previous CPU mode was
>> >> "0"(kernel), and the interrupt vectors were mapped "natively" at
>> VA 0
>> >> in kernel?
>> >>
Anton Lavrentiev
Jun 18, 2024, 10:47:00 PMJun 18
to Johnny Billquist, pid...@googlegroups.com
Thanks again, Johnny.
So the user task should never "see" previous mode as kernel (or supervisor) in the PSW, so that it can't circumvent the protection and clobber (or "steal") something it isn't supposed to.
I guess "supervisor" mode tasks should also only have "supervisor" or "user" (never "kernel") as the previous mode, for the same reason.
And only "kernel" mode code can have anything as its previous mode.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/4d9a37c1-82a5-49f3-9919-7ed3b4cdf18e%40softjar.se.
Johnny Billquist
Jun 19, 2024, 5:28:33 AMJun 19
to Anton Lavrentiev, pid...@googlegroups.com
On 2024-06-19 04:46, Anton Lavrentiev wrote:
> Thanks again, Johnny.
>
> So the user task should never "see" previous mode as kernel (or
> supervisor) in the PSW, so that it can't circumvent the protection and
> clobber (or "steal") something it isn't supposed to.
Correct.
> Thanks again, Johnny.
>
> So the user task should never "see" previous mode as kernel (or
> supervisor) in the PSW, so that it can't circumvent the protection and
> clobber (or "steal") something it isn't supposed to.
> I guess "supervisor" mode tasks should also only have "supervisor"or
> "user" (never "kernel") as the previous mode, for the same reason.
> And only "kernel" mode code can have anything as its previous mode.
libraries, and if a user program calls routines in such a library, then
previous mode, while in the library, is usermode, so the library can
access the memory of the caller. When you get back to usermode, previous
mode is usermode, so you can't from usermode poke at the supervisor mode
library.
Johnny
> >>
> >> I should perhaps point out that when you areat user level, the
> >> previous
> >> mode is normally also set at user level. It's just when you
> have
> >> traps
> >> or interrupts that the previous level gets set up from the
> current
> >> level, so that the kernel/hardware knows which level it came
> from.
> >>
> >> Johnny
> >>
> >> On 2024-06-19 03:40, Johnny Billquist wrote:
> >> > It's simple. Previous space is takenfrom the PSW. And in
> >> mode is normally also set at user level. It's just when you
> have
> >> traps
> >> or interrupts that the previous level gets set up from the
> current
> >> level, so that the kernel/hardware knows which level it came
> from.
> >>
> >> Johnny
> >>
> >> On 2024-06-19 03:40, Johnny Billquist wrote:
> user
> >> level you
> >> > cannot change that part of PSW, so it's basically not
> possible to
> >> use it
> >> > to circumvent memory protection. Butit's useful in the
> >> level you
> >> > cannot change that part of PSW, so it's basically not
> possible to
> >> use it
> >> >> <mailto:pidp-11+u...@googlegroups.com
> <mailto:pidp-11%2Bu...@googlegroups.com>>.
> >> >> To view this discussion on the web visit
> >> >>
> >>
> >>
> https://groups.google.com/d/msgid/pidp-11/b21fd329-f794-4548-9bd8-596e42a07196n%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/b21fd329-f794-4548-9bd8-596e42a07196n%40googlegroups.com> <https://groups.google.com/d/msgid/pidp-11/b21fd329-f794-4548-9bd8-596e42a07196n%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/b21fd329-f794-4548-9bd8-596e42a07196n%40googlegroups.com>> <https://groups.google.com/d/msgid/pidp-11/b21fd329-f794-4548-9bd8-596e42a07196n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/pidp-11/b21fd329-f794-4548-9bd8-596e42a07196n%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/pidp-11/b21fd329-f794-4548-9bd8-596e42a07196n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/pidp-11/b21fd329-f794-4548-9bd8-596e42a07196n%40googlegroups.com?utm_medium=email&utm_source=footer>>>.
> >> >>
> >>
> >>
> >> >
> >>
> >> -- Johnny Billquist || "I'm on abus
> >> || on a psychedelic trip
> >> email: b...@softjar.se <mailto:b...@softjar.se> || Reading
> >>
> >> -- Johnny Billquist || "I'm on abus
> >> || on a psychedelic trip
> murder books
> >> pdp is alive! || tryin' to stay hip" - B. Idol
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "[PiDP-11]" group.
> >> To unsubscribe from this group and stop receiving emails from
> it, send
> >> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11%2Bunsu...@googlegroups.com>
> >> pdp is alive! || tryin' to stay hip" - B. Idol
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "[PiDP-11]" group.
> >> To unsubscribe from this group and stop receiving emails from
> it, send
> >> an email to pidp-11+u...@googlegroups.com
> >> <mailto:pidp-11+u...@googlegroups.com
> <mailto:pidp-11%2Bunsu...@googlegroups.com>>.
> >> To view this discussion on the web visit
> >>
> https://groups.google.com/d/msgid/pidp-11/8a5eeb38-6d6b-43a1-9935-d281e03a0c82n%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/8a5eeb38-6d6b-43a1-9935-d281e03a0c82n%40googlegroups.com> <https://groups.google.com/d/msgid/pidp-11/8a5eeb38-6d6b-43a1-9935-d281e03a0c82n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/pidp-11/8a5eeb38-6d6b-43a1-9935-d281e03a0c82n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> >>
> >
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: b...@softjar.se <mailto:b...@softjar.se> ||
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11%2Bunsu...@googlegroups.com>.
> pdp is alive! || tryin' to stay hip" - B. Idol
>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to pidp-11+u...@googlegroups.com
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/4d9a37c1-82a5-49f3-9919-7ed3b4cdf18e%40softjar.se <https://groups.google.com/d/msgid/pidp-11/4d9a37c1-82a5-49f3-9919-7ed3b4cdf18e%40softjar.se>.
Reply all
Reply to author
Forward
0 new messages