[TUHS] pdp11 UNIX memory allocation.

[TUHS] pdp11 UNIX memory allocation.

[Johnny Billquist]

On 2015-01-06 20:57, Milo Velimirovi?<milov at cs.uwlax.edu> wrote:
> Bringing a conversation back online.
> On Jan 6, 2015, at 6:22 AM,arnold at skeeve.com  wrote:
>
>>> >>Peter Jeremy scripsit:
>>>> >>>But you pay for the size of $TERMCAP in every process you run.
>> >
>> >John Cowan<cowan at 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?

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 at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[TUHS] pdp11 UNIX memory allocation.

[random832]

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.)

[TUHS] pdp11 UNIX memory allocation.

[Ronald Natalie]

> On Jan 6, 2015, at 3:33 PM, random832 at 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] pdp11 UNIX memory allocation.

[Clem Cole]

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 at ronnatalie.com> wrote:

>
> > On Jan 6, 2015, at 3:33 PM, random832 at 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 at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/2c5538dc/attachment.html>

[TUHS] pdp11 UNIX memory allocation.

[Ronald Natalie]

And then of course there was the famous ISVTX bit (also known as the sticky or t bit).

[TUHS] pdp11 UNIX memory allocation.

[Dave Horsfall]

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)

[TUHS] pdp11 UNIX memory allocation.

[Ronald Natalie]

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 at 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...

[TUHS] pdp11 UNIX memory allocation.

[Dave Horsfall]

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] pdp11 UNIX memory allocation.

[Warren Toomey]

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] pdp11 UNIX memory allocation.

[Brantley Coile]

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 at 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 at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150107/7c83f212/attachment.html>

[TUHS] pdp11 UNIX memory allocation.

[Jacob Ritorto]

>
> 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 at 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 at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150107/295c1465/attachment.html>

[TUHS] pdp11 UNIX memory allocation.

[random832]

Apparently the message I was replying to was off-list, but it seems like
a waste to have typed all this out (including answering my own question)
and have it not go to the list.

On Tue, Jan 6, 2015, at 17:35, random832 at fastmail.us wrote:
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/factor.s
> wrchar:
> 	mov     r0,ch
> 	mov     $1,r0
> 	sys     write; ch; 1
> 	rts     r5
> 
> Though it looks like the C wrappers use the "indirect" system call which
> reads a "fake" trap instruction from the data segment. Looking at the
> implementation of that, my question is answered:
> 
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/sys/sys/trap.c
> 		if (callp == sysent) { /* indirect */
> 			a = (int *)fuiword((caddr_t)(a));
> 			pc++;
> 			i = fuword((caddr_t)a);
> 			a++;
> 			if ((i & ~077) != SYS)
> 				i = 077;        /* illegal */
> 			callp = &sysent[i&077];
> 			fetch = fuword;
> 		} else {
> 			pc += callp->sy_narg - callp->sy_nrarg;
> 			fetch = fuiword;
> 		}
> 
> http://minnie.tuhs.org/TUHS/Archive/PDP-11/Trees/V7/usr/man/man2/indir.2
> The main purpose of indir is to allow a program to
> store arguments in system calls and execute them
> out of line in the data segment.
> This preserves the purity of the text segment.
> 
> Note also the difference between V2 and V5 libc - clearly support for
> split I/D machines was added some time in this interval.
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=V2/lib/write.s
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s4/write.s

[TUHS] pdp11 UNIX memory allocation

[Johnny Billquist]

On 2015-01-06 22:59, random832 at fastmail.us wrote:
> 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.)

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 at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[TUHS] pdp11 UNIX memory allocation

[Ronald Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

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.

[TUHS] pdp11 UNIX memory allocation

[Johnny Billquist]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2110 bytes --]

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 at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[TUHS] pdp11 UNIX memory allocation

[John Cowan]

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 at 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

[TUHS] pdp11 UNIX memory allocation

[Johnny Billquist]

On 2015-01-07 03:39, John Cowan wrote:
> 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.

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 at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[TUHS] pdp11 UNIX memory allocation.

[Noel Chiappa]

    > From: Clem Cole <clemc at ccc.com>

    > Depends the processor. For the 11/45 class processors, you had a 17th
    > address bit, which was the I/D choice. For the 11/40 class you shared
    > the instructions and data space.

To be exact, the 23, 24, 34, 35/40 and 60 all had a single shared space.
(I have no idea why DEC didn't put it in the 60 - probably helped kill that

otherwise intersting machine, with its UCS, early...). The 44, 45/50/55, 70,
73, 83/84, and 93/94 had split.


    > From: random832 at fastmail.us

    > 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.)

Here's the code for a typical 'wrapper' (this is V6, not sure if V7 changed
the trap stuff):

  _lseek:
	jsr	r5,csv
	mov	4(r5),r0
	mov	6(r5),0f
	mov	8(r5),0f+2
	mov	10.(r5),0f+4
	sys	indir; 9f
	bec	1f
	jmp	cerror
  1:
	jmp	cret

  .data
  9:
	sys	lseek; 0:..; ..; ..

Note the switch to data space for storing the arguments (at the 0: label
hidden in the line of data), and the 'indirect' system call.


    > From: Ronald Natalie <ron at ronnatalie.com>

    > Some access at the kernel level can be done with MFPI and MPFD
    > instructions.

Unless you hacked your hardware, in which case it was possible from user mode
too... :-)

I remember how freaked out we were when we tried to use MFPI to read
instruction space, and it didn't work, whereupon we consulted the 11/45
prints, only to discover that DEC had deliberately made it not work!


    > From: Ronald Natalie <ron at ronnatalie.com>

    > After the changes to the FS, you'd get missing blocks and a few 0-0
    > inodes (or ones where the links count was higher than the links). These
    > while wasteful were not going to cause problems.

It might be worth pointing out that due to the way pipes work, if a system
crashed with pipes open, even (especially!) with the disk perfectly sync'd,
you'll be left with 0-0 inodes. Although as you point out, those were merely
crud, not potential sourdes of file-rot.

	Noel

[TUHS] pdp11 UNIX memory allocation.

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

On Tue, Jan 6, 2015 at 5:45 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> I have no idea why DEC didn't put it in the 60 - probably helped kill that
> otherwise intersting machine, with its UCS, early...
>

​"Halt and confuse ucode" had a lot to do with it IMO.

FYI: The 60 set the record of going from production to "traditional
products" faster than​ anything else in DEC's history.     As I understand
it, the 11/60 was expected to a business system and run RSTS.  Why the WCS
was put in, I never understood, other than I expect the price of static RAM
had finally dropped and DEC was buying it in huge quantities for the
Vaxen.  The argument was that they could update the ucode cheaply in the
field (which to my knowledge the never did).   But I asked that question
many years ago to one of the HW manager, who explained to me that it was
felt separate I/D was not needed for the targeted market and would have
somehow increased cost.   I don't understand why it would have cost any
more but I guess it was late.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/dbeb090b/attachment.html>

[TUHS] pdp11 UNIX memory allocation.

[Johnny Billquist]

On 2015-01-06 23:56, Clem Cole<clemc at ccc.com> wrote:
>
> On Tue, Jan 6, 2015 at 5:45 PM, Noel Chiappa<jnc at mercury.lcs.mit.edu>
> wrote:
>
>> >I have no idea why DEC didn't put it in the 60 - probably helped kill that
>> >otherwise intersting machine, with its UCS, early...
>> >
> ?"Halt and confuse ucode" had a lot to do with it IMO.
>
> FYI: The 60 set the record of going from production to "traditional
> products" faster than? anything else in DEC's history.     As I understand
> it, the 11/60 was expected to a business system and run RSTS.  Why the WCS
> was put in, I never understood, other than I expect the price of static RAM
> had finally dropped and DEC was buying it in huge quantities for the
> Vaxen.  The argument was that they could update the ucode cheaply in the
> field (which to my knowledge the never did).   But I asked that question
> many years ago to one of the HW manager, who explained to me that it was
> felt separate I/D was not needed for the targeted market and would have
> somehow increased cost.   I don't understand why it would have cost any
> more but I guess it was late.

No, field upgrade of microcode can not have been it. The WCS for the 
11/60 was an option. Very few machines actually had it. It was for 
writing your own extra microcode as addition to the architecture.
The basic microcode for the machine was in ROM, just like on all the 
other PDP-11s. And DEC sold a compiler and other programs required to 
develop microcode for the 11/60. Not that I know of anyone who had them. 
I've "owned" four PDP-11/60 systems in my life. I still have a set of 
boards for the 11/60 CPU, but nothing else left around.

The 11/60 was, by the way, not the only PDP-11 with WCS. The 11/03 (if I 
remember right) also had such an option. Obviously the microcode was not 
compatible between the two machines, so you couldn't move it over from 
one to the other.

Also, reportedly, someone at DEC implemented a PDP-8 on the 11/60, 
making it the fastest PDP-8 ever manufactured. I probably have some 
notes about it somewhere, but I'd have to do some serious searching if I 
were to dig that up.

But yes, the 11/60 went from product to "traditional" extremely fast.

Split I/D space was one omission from the machine, but even more serious 
was the decision to only do 18-bit addressing on it. That killed it very 
fast.

Someone else mentioned the MFPI/MFPD instructions as a way of getting 
around the I/D restrictions. As far as I know (can tell), they are 
possible to use to read/write instruction space on a machine. I would 
assume that any OS would set both current and previous mode to user when 
executing in user space.
The documentation certainly claims they will work. I didn't think of 
those previously, but they would allow you to read/write to instruction 
space even when you have split I/D space enabled.

	Johnny

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

[TUHS] pdp11 UNIX memory allocation.

[scj]

>> ...Why the WCS was put in, I never understood, other than I expect
>> the price of static RAM had finally dropped and DEC was buying it
>> in huge quantities for the Vaxen...

The Interdata 8/32, Bell Labs' first 32-bit Unix port target, had writable
microcode.  It added a rather modest amount to the cost of the system as I
remember (about $8K).  Unfortunately, it was pretty useless.  The
instruction format, like many machines at the time, had opcodes and then
some of the instruction bits were use to get the operands -- register,
memory, offsets from registers, etc.  The operand handling was implemented
in hardware, and any added instructions could not use get to this operand
hardware.  So any new instructions that were added were pretty crippled.

Moreover, the implementation in microcode was flawed.  If you tried to
load a word through a pointer that had a -1 in it (a common error in
earlier Unices where -1 was an error return from the OS), you actually got
two faults--a memory bounds error and an alignment check.  Unfortunately,
these faults came at slightly different times--the alignment check
executed 2 or 3 micro instructions and then the bounds check arrived,
reset the microcode and lost all the status information.  Not only was the
fault unrecoverable but the only way to clear it was to power cycle the
processor!

A bunch of us went to talk to the manufacturer and said, in effect, "We
like your machine but we won't buy any more until this fault recovery
problem is fixed".  It was like talking to a bunch of cinder blocks --
they just didn't get it.  Shortly afterwards the VAX arrived and the rest
was history...

[TUHS] pdp11 UNIX memory allocation.

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]

On Tue, Jan 6, 2015 at 6:34 PM, Johnny Billquist <bqt at update.uu.se> wrote:

> The basic microcode for the machine was in ROM, just like on all the other
> PDP-11s. And DEC sold a compiler and other programs required to develop
> microcode for the 11/60. Not that I know of anyone who had them. I've
> "owned" four PDP-11/60 systems in my life. I still have a set of boards for
> the 11/60 CPU, but nothing else left around.


I did not realized it was an option.  ​IIRC we had it on the Teklabs 11/60,
but we could not run the tools easily so we ended up never messing with it.
  We had talked about adding the CMU csav/cret instructs from the 11/40e
but we got the 11/70 and that sucked up my time and I never got back to try
it.

It was not a redux of the 11/34 BTW.  Jeff Mitchell did the 11/34 and was
off working on the 750 when the 60 was done.  I believe Al Pat was somehow
involved with 60, but I've forgotten.

As for the "halt and confuse uCode" stuff.  The 60 was notorious for
getting "stuck" when running UNIX.    I've now forgotten many of the
details, IIRC it had to with context switch, register save and I think I
remember it was something to do with multiple interrupts.   Since Glaser
and I did the original 11/60 port, I think we knew most of the USENIX UNIX
sites that run it on them since we swapped notes if not code.  All of us
used to complain about random hangs where the uCode take a jump and the
system would halt.    The only solution when that happened was the pull the
circuit breaker power on the back of the machine because the front panel
switched were lost.   I personally spend many hours with the DEC guys
trying to figure what is was, we could never repeat it.   Years later, when
I got to know some of the uCode engineers that had worked on the 11s and
the Vaxen, I found out it was agreed at DEC engineer there was a uCode bug,
but so few UNIX customer were out there (and the system had gone to
"traditional products") management dropped as not being worth finding and
fixing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150107/eb826931/attachment.html>

[TUHS] pdp11 UNIX memory allocation.

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]

On Wed, 7 Jan 2015, Clem Cole wrote:

> I did not realized it [WCS] was an option.  ​IIRC we had it on the 
> Teklabs 11/60, but we could not run the tools easily so we ended up 
> never messing with it.

Our 11/60 certainly had it; I remember scouring the manual, trying to make 
sense of it, but after five years studying at UNSW and eight years working 
there (almost got long service leave!) I got itchy feet.  Besides, 
although the CSU was a great place to work, I didn't like the plans to 
merge it with the Chancellery (the bureaucratic centre), lest I come to 
work one morning and find myself working on a COBOL program...

The provenance of the beast was that apparently a deal with some big 
publishing house fell through (Limited News, perhaps?) and DEC was stuck 
with a warehouse full of them; it seems the WCS was to be used for the 
typesetting or something, I dunno; they could always have yanked the WCS?

[...]

> The only solution when that happened was the pull the circuit breaker 
> power on the back of the machine because the front panel switched were 
> lost.

Don't all 11s have the same key?  I used to carry one on my key-ring.

-- 
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] pdp11 UNIX memory allocation.

[Noel Chiappa]

    > From: Ronald Natalie <ron at ronnatalie.com>

    > Yep, the only time this was ever trully useful was so you could put an
    > a.out directly into the boot block I think.

Well, sort of. If you had non position-independent code, it would blow out
(it would be off by 020). Also, some bootstraps (e.g. the RL, IIRC) were so
close to 512. bytes long that the extra 020 was a problem. And it was so easy
to strip off:

   dd if=a.out of=fooboot bs=1 skip=16

I'm not sure that anything actually used the fact that 407 was 'br .+020', by
the V6 era; I think it was just left over from older Unixes (where it was not
in fact stripped on loading). Not just on executables running under Unix; the
boot-loader also stripped it, so it wasn't even necessary to strip the a.out
header off /unix.

	Noel

[TUHS] pdp11 UNIX memory allocation.

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 692 bytes --]

On Tue, Jan 6, 2015 at 9:18 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> I'm not sure that anything actually used the fact that 407 was 'br .+020',
> by
> the V6 era; I think it was just left over from older Unixes (where it was
> not
> in fact stripped on loading). Not just on executables running under Unix;
> the
> boot-loader also stripped it, so it wasn't even necessary to strip the
> a.out
> header off /unix.
>

​If you look at the first edition code that Warren has, that seems to
support it.

Clem​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150107/6356e917/attachment.html>