6 Jan
2015
6 Jan
'15
9:20 p.m.
On 2015-01-06 20:57, Milo Velimirovi?<milov(a)cs.uwlax.edu> wrote:
Bringing a conversation back online.
On Jan 6, 2015, at 6:22 AM,arnold(a)skeeve.com wrote:
You are conflating two things. :-)
A standard PDP-11 have 64Kb of virtual memory space. This can be divided
any way you want between data and code.
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.
(This also means that the text you quoted was incorrect, as it stated
that you had 32Kb, which is incorrect. It was/is 32 Kword.)
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
> >>Peter Jeremy scripsit:
>> >>>But you pay for the size of $TERMCAP in every process you run.
>
>John Cowan<cowan(a)mercury.ccil.org> wrote:
> >>A single termcap line doesn't cost that much, less than a KB in most
cases.
>
>In 1981 terms, this has more weight. On a non-split I/D PDP-11 you only
>have 32KB to start with. (The discussion a few weeks ago about cutting
>yacc down to size comes to mind?)
(Or even earlier than ?81.) How did pdp11
UNIXes handle per process memory? It?s suggested above that there was a 50-50 split of the
64KB address space between instructions and data. My own recollection is that you got any
combination of instruction and data space that was <64KB. This would also be subject to
limits of pdp11 memory management unit.
Anyone have a definitive answer or pointer to appropriate man page or source code?
6 Jan
6 Jan
9:33 p.m.
New subject: pdp11 UNIX memory allocation.
On Tue, Jan 6, 2015, at 15:20, Johnny Billquist wrote:
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.)
10:57 p.m.
New subject: pdp11 UNIX memory allocation.
On Jan 6, 2015, at 3:33 PM, random832(a)fastmail.us
wrote:
Was it possible to read/write to the instruction space, or execute the
data space?
In split I/D mode (411) magic number. It is imposible to execute in D space or use
regular data access instructions to access i-space. The addresses are in completely
different spaces (i.e, 0 in data is mapped to different memory than 0 in instruction
space). Some access at the kernel level can be done with MFPI and MPFD instructions.
In write protected, non-split more (410 magic), you could read the I space and you could
jump in to D space. You were prohibited to write the i space.
In non protected mode (407 magic) everything was fair game.
11 p.m.
New subject: pdp11 UNIX memory allocation.
Right - that's how the kernel set up the page tables for the user processes.
On Tue, Jan 6, 2015 at 4:57 PM, Ronald Natalie <ron(a)ronnatalie.com> wrote:
On Jan 6, 2015, at 3:33 PM, random832(a)fastmail.us
wrote:
Was it possible to read/write to the instruction space, or execute the
data space?
In split I/D mode (411) magic number. It is imposible to execute in D
space or use regular data access instructions to access i-space. The
addresses are in completely different spaces (i.e, 0 in data is mapped to
different memory than 0 in instruction space). Some access at the kernel
level can be done with MFPI and MPFD instructions.
In write protected, non-split more (410 magic), you could read the I space
and you could jump in to D space. You were prohibited to write the i
space.
In non protected mode (407 magic) everything was fair game.
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
11:04 p.m.
New subject: pdp11 UNIX memory allocation.
And then of course there was the famous ISVTX bit (also known as the sticky or t bit).
7 Jan
7 Jan
2:46 a.m.
New subject: pdp11 UNIX memory allocation.
On Tue, 6 Jan 2015, Ronald Natalie wrote:
In non protected mode (407 magic) everything was fair
game.
Which reminds me, I wonder how many people know that "407" was the 40's
instruction that, if the a.out header was present, would neatly skip over
it...
--
Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)
3 a.m.
New subject: pdp11 UNIX memory allocation.
Yep, the only time this was ever trully useful was so you could put an a.out directly into
the boot block I think.
During normal operations the a.out header was never actually loaded into the user memory.
On Jan 6, 2015, at 8:46 PM, Dave Horsfall
<dave(a)horsfall.org> wrote:
On Tue, 6 Jan 2015, Ronald Natalie wrote:
In non protected mode (407 magic) everything was
fair game.
Which reminds me, I wonder how many people know that "407" was the 40's
instruction that, if the a.out header was present, would neatly skip over
it...
7:29 a.m.
New subject: pdp11 UNIX memory allocation.
On Tue, 6 Jan 2015, Ronald Natalie wrote:
Yep, the only time this [the 407 magic number] was
ever trully useful
was so you could put an a.out directly into the boot block I think.
But why would you include an a.out header in a boot block? When you only
had 512 bytes, every one of 'em counted, and I, oops, I mean others, had
to resort to vile stuff such as self-modifying code...
During normal operations the a.out header was never
actually loaded into
the user memory.
I heard a story that on sufficiently-early Unices, the header was indeed
loaded, hence the "407".
Any grey-beards here like to comment?
--
Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)
7:39 a.m.
New subject: pdp11 UNIX memory allocation.
On Wed, Jan 07, 2015 at 05:29:45PM +1100, Dave Horsfall wrote:
I heard a story that on sufficiently-early Unices, the
header was indeed
loaded, hence the "407".
Any grey-beards here like to comment?
My beard isn't grey (yet), but here's the link to the 1st Edition code
which does exec(2):
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/u2.s
and here is the relevant code:
mov $14,u.count
mov $u.off,u.fofp
clr u.off / set offset in file to be read to zero
jsr r0,readi / read in first six words of user's file, starting
/ at $core
mov sp,r5 / put users stack address in r5
sub $core+40.,r5 / subtract $core +40, from r5 (leaves
/ number of words less 26 available for
/ program in user core
mov r5,u.count /
cmp core,$405 / br .+14 is first instruction if file is
/ standard a.out format
bne 1f / branch, if not standard format
mov core+2,r5 / put 2nd word of users program in r5; number of
/ bytes in program text
sub $14,r5 / subtract 12
cmp r5,u.count /
bgt 1f / branch if r5 greater than u.count
mov r5,u.count
jsr r0,readi / read in rest of user's program text
add core+10,u.nread / add size of user data area to u.nread
br 2f
1:
jsr r0,readi / read in rest of file
My memory of PDP-11 assembly is too rusty to interpret this. Anybody else?
Cheers, Warren
11:06 a.m.
New subject: pdp11 UNIX memory allocation.
It indeed executes the magic number. The comment at the end of sysexec says it executes
the code at $core, which has the twelve word header still in it. Notice that the magic
number is two less than the later formats; 0405 instead of 0407. This most likely means
that the header was still in the address space in later versions even after another two
words were added to the header.
Brantley
Sent from my iPad
On Jan 7, 2015, at 1:39 AM, Warren Toomey
<wkt(a)tuhs.org> wrote:
On Wed, Jan 07, 2015 at 05:29:45PM +1100, Dave
Horsfall wrote:
I heard a story that on sufficiently-early Unices, the header was indeed
loaded, hence the "407".
Any grey-beards here like to comment?
My beard isn't grey (yet), but here's the link to the 1st Edition code
which does exec(2):
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/u2.s
and here is the relevant code:
mov $14,u.count
mov $u.off,u.fofp
clr u.off / set offset in file to be read to zero
jsr r0,readi / read in first six words of user's file, starting
/ at $core
mov sp,r5 / put users stack address in r5
sub $core+40.,r5 / subtract $core +40, from r5 (leaves
/ number of words less 26 available for
/ program in user core
mov r5,u.count /
cmp core,$405 / br .+14 is first instruction if file is
/ standard a.out format
bne 1f / branch, if not standard format
mov core+2,r5 / put 2nd word of users program in r5; number of
/ bytes in program text
sub $14,r5 / subtract 12
cmp r5,u.count /
bgt 1f / branch if r5 greater than u.count
mov r5,u.count
jsr r0,readi / read in rest of user's program text
add core+10,u.nread / add size of user data area to u.nread
br 2f
1:
jsr r0,readi / read in rest of file
My memory of PDP-11 assembly is too rusty to interpret this. Anybody else?
Cheers, Warren
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs 
2:29 p.m.
New subject: pdp11 UNIX memory allocation.
But why would you include an a.out header in a boot block? When you only
had 512 bytes, every one of 'em counted, and I, oops, I mean others, had
to resort to vile stuff such as self-modifying code...
Ooh, can we see annotated examples? This is the really delicious stuff!
I heard a story that on sufficiently-early Unices, the header was indeed
loaded, hence the "407".
Any grey-beards here like to comment?
+1 for hearing that and wanting to see annotated examples of it as well!
On Wed, Jan 7, 2015 at 1:29 AM, Dave Horsfall <dave(a)horsfall.org> wrote:
On Tue, 6 Jan 2015, Ronald Natalie wrote:
Yep, the only time this [the 407 magic number]
was ever trully useful
was so you could put an a.out directly into the boot block I think.
But why would you include an a.out header in a boot block? When you only
had 512 bytes, every one of 'em counted, and I, oops, I mean others, had
to resort to vile stuff such as self-modifying code...
During normal operations the a.out header was
never actually loaded into
the user memory.
I heard a story that on sufficiently-early Unices, the header was indeed
loaded, hence the "407".
Any grey-beards here like to comment?
--
Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're
there)
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
3603
days inactive
3604
days old
10 comments
8 participants
participants (8)
-
Brantley Coile -
Clem Cole -
Dave Horsfall -
Jacob Ritorto -
Johnny Billquist -
random832＠fastmail.us -
Ronald Natalie -
Warren Toomey