6 Jan
2015
6 Jan
'15
10:20 p.m.
On 2015-01-06 22:59, random832(a)fastmail.us wrote:
On Tue, Jan 6, 2015, at 15:20, Johnny Billquist
wrote:
Nope. A process cannot read or write to instruction space, nor can it
execute from data space.
It's inherent in the MMU. All references related to the PC will be done
from I-space, while everything else will be done through D-space.
So the MMU have two sets of page registers. One set maps I-space, and
another maps D-space. Of course, you can have them overlap, in which
case you get the traditional appearance of older models.
The versions of Unix I am aware of push arguments on the stack. But of
course, the kernel can remap memory, and so can of course read the
instruction space. But the user program itself would not be able to
write anything after the trap instruction.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
>Later model PDP-11 processors had a hardware
feature called split I/D
>space. This meant that you could have one 64Kb virtual memory space for
>instructions, and one 64Kb virtual memory space for data.
Was it possible to
read/write to the instruction space, or execute the
data space? From what I've seen, the calling convention for PDP-11 Unix
system calls read their arguments from directly after the trap
instruction (which would mean that the C wrappers for the system calls
would have to write their arguments there, even if assembly programs
could have them hardcoded.) 
6 Jan
6 Jan
10:36 p.m.
New subject: pdp11 UNIX memory allocation
Another quaint bit of history was when we made the jump to actually running the kernel in
split-I/D mode. My good friend Joe Pistritto wrote the JHU boot loader for that. The
512-byte boot loader that was the standard UNIX one was used to load Joe’s split I/D
booter. It had a better support of the UNIX file system, but the question was how do you
get from a non-split I/D program into the split I/D program. Joe’s solution was rather
clever. He put an instruction that stored the processor status word with the new kernel
mode at the top of the boot loader’s address space. As he did the store the PC rolled
over and now it was running at the new mode at location zero.
Years later I found that others had solved the problem by just setting up the kernel
registers and executing a trap which switched the modes. I always thought Joe’s
solution was more elegant. The kernel started the same way any other UNIX program would
start.
11:14 p.m.
New subject: pdp11 UNIX memory allocation
On 2015-01-06 23:36, Ronald Natalie wrote:
Another quaint bit of history was when we made the
jump to actually running the kernel in split-I/D mode. My good friend Joe Pistritto
wrote the JHU boot loader for that. The 512-byte boot loader that was the standard UNIX
one was used to load Joe’s split I/D booter. It had a better support of the UNIX file
system, but the question was how do you get from a non-split I/D program into the split
I/D program. Joe’s solution was rather clever. He put an instruction that stored the
processor status word with the new kernel mode at the top of the boot loader’s address
space. As he did the store the PC rolled over and now it was running at the new mode at
location zero.
??? Are you sure you remember that right?
The change from non split I/D to split I/D is not in the processor
status word. Also, the last address of memory, before you enable the
MMU, is actually the PSW. You can't have code there.
Years later I found that others had solved the problem
by just setting up the kernel registers and executing a trap which switched the modes.
I always thought Joe’s solution was more elegant. The kernel started the same way any
other UNIX program would start.
I'm probably missing a whole bunch of detail here, as I'm not fully
following what was done.
Also, I fail to even spot the problem. Enabling split I/D space is just
a bit in the MMU, but even after, you can have the same memory pages in
both page tables, in essence making it a noop. Of course, being able to
have data outside your code means you can have so much more code, in
addition to more data, that you'd just would want to keep them split.
But that means just setting up the two page tables appropriately, load
the memory as needed, and then enable the MMU and the split I/D, and
you're done.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
7 Jan
7 Jan
2:39 a.m.
New subject: pdp11 UNIX memory allocation
Johnny Billquist scripsit:
The versions of Unix I am aware of push arguments on
the stack.
Yes. It was typical for HLLs not to use JSR Rn instructions (which you
need if you are going to pull arguments out of the instruction stream)
but rather JSR PC instructions.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
Long-short-short, long-short-short / Dactyls in dimeter,
Verse form with choriambs / (Masculine rhyme):
One sentence (two stanzas) / Hexasyllabically
Challenges poets who / Don't have the time. --robison who's at texas dot
net
2:59 a.m.
New subject: pdp11 UNIX memory allocation
On 2015-01-07 03:39, John Cowan wrote:
Johnny Billquist scripsit:
True. However, in this particular case, we were talking about system
calls. But the versions of the code I was aware of were equally much
pushing stuff on the stack for that case.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
The versions of Unix I am aware of push arguments
on the stack.
Yes. It was typical for HLLs not to use JSR Rn instructions (which you
need if you are going to pull arguments out of the instruction stream)
but rather JSR PC instructions.
3406
days inactive
3407
days old
4 comments
3 participants
participants (3)
-
John Cowan -
Johnny Billquist -
Ronald Natalie