[TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)

[TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)

[Noel Chiappa]

    > From: Clem Cole

    > A new hire in 1976, Jeff Mitchell supposedly had a bet with Bill
    > Strecker that he could implement an 11 on a single"hex high" CPU board
    > if he got rid of the lights and switches. He ran out of room to
    > implement seperate I/D, so it became an 11/40 class [and it has an
    > 8008-1 that runs the front panel].

I don't know about the Strecker story, but the first PDP-11 CPU on a single
card (a hex card) was the KD11-D:

  https://gunkies.org/wiki/KD11-D_CPU

of the -11/04. It didn't have _any_ memory management, though (or a front
panel; to get that, you had to use the KY"11-LB:

  https://gunkies.org/wiki/KY11-LB_Programmer%27s_Console

which added another quad card). The first -11 CPU i) on a single card and
ii) with memory management was the FDF11-A:

  https://gunkies.org/wiki/KDF11-A_CPU

The first -11 CPU i) on a single card and ii) with split I+D memory
management was the KDJ11-A.


    > It was not until 11/44 that DEC was able to make a hex height
    > implementation of the 11 that managed to cram a full 11/70 into that
    > system.

I'm not sure what your point is here? The KD11-Z CPU of the -11/44:

  https://gunkies.org/wiki/KD11-Z_CPU

was a _minimum_ of five hex boards; a little smaller than a KB11-B (15 hex
cards). Floating point was an extra card; CIS was 2 more. 


    > if you look at the link line of sys/run the 45 does not have -i

Split I+D for the kernel was not supported by the linker in V6; a combination
of 'sysfix' (a special post-processor, which took as input a relocatable
linked image) and code in m45.s was needed.

  https://gunkies.org/wiki/Upgrading_UNIX_Sixth_Edition
  https://gunkies.org/wiki/UNIX_V6_memory_layout

The code in m45.s to handle split I+D in the kernel:

  https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/conf/m45.s

starts at 'start:' and is adequately commented to tell you what it's doing
when it plays around with kernel memory.



    > From: Will Senn

    > with I/D, you can use 64k for I and 64k for D. Was that it, or were
    > there other tricks to get even more allocated

I have this vague memory that someone (Berkeley, I think?) added support for
automatic code overlays in user processes. The programmer had to decide which
modules went in which overlays, but after that it was all automagic. There
was a 4xx code allocated to them.

I think the support for that (in e.g. the linker) was somehow involved with
the use of overlays in the kernel, but I don't know the details (nothing
after V6 is at all interesting to me).

    > didn't the 11 max out at 256k)?

You need to distinguish between i) the amount of memory the machine could
handle, and ii) the amount of memory that running code could 'see' at any
instant. The latter was always either 64KB, or 64KB+64KB (with split I+D
turned on, on CPUs which supported it).

The former, it's complicated. Mostly, on UNIBUS only machines, it was 256KB.
(Although there was the Able ENABLE:

  https://gunkies.org/wiki/Able_ENABLE

which added an Extended UNIBUS, and could take them up to 4MB.) The -11/70,
as mentioned, had a Main Memory Bus, and could handle up to 4MB. The -11/44
had an Extended UNIBUS, and could also handle up to 4MB (but only after the
MS11-P became available; there were only 4 main memory slots in the
backplane, and MS11-M cards were only 256KB.) On QBUS achines, after the
KB11-A (Revision A), which only suppported 256 KB, all later revisions and
CPUs could also handle up to 4MB.

	Noel

[TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 3939 bytes --]

On Thu, Aug 3, 2023, 5:10 PM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

>     > From: Clem Cole
>
>     > A new hire in 1976, Jeff Mitchell supposedly had a bet with Bill
>     > Strecker that he could implement an 11 on a single"hex high" CPU
> board
>     > if he got rid of the lights and switches. He ran out of room to
>     > implement seperate I/D, so it became an 11/40 class [and it has an
>     > 8008-1 that runs the front panel].
>
> I don't know about the Strecker story, but the first PDP-11 CPU on a single
> card (a hex card) was the KD11-D:
>
>   https://gunkies.org/wiki/KD11-D_CPU
>
> of the -11/04. It didn't have _any_ memory management, though (or a front
> panel; to get that, you had to use the KY"11-LB:
>
>   https://gunkies.org/wiki/KY11-LB_Programmer%27s_Console
>
> which added another quad card). The first -11 CPU i) on a single card and
> ii) with memory management was the FDF11-A:
>
>   https://gunkies.org/wiki/KDF11-A_CPU
>
> The first -11 CPU i) on a single card and ii) with split I+D memory
> management was the KDJ11-A.
>
>
>     > It was not until 11/44 that DEC was able to make a hex height
>     > implementation of the 11 that managed to cram a full 11/70 into that
>     > system.
>
> I'm not sure what your point is here? The KD11-Z CPU of the -11/44:
>
>   https://gunkies.org/wiki/KD11-Z_CPU
>
> was a _minimum_ of five hex boards; a little smaller than a KB11-B (15 hex
> cards). Floating point was an extra card; CIS was 2 more.
>
>
>     > if you look at the link line of sys/run the 45 does not have -i
>
> Split I+D for the kernel was not supported by the linker in V6; a
> combination
> of 'sysfix' (a special post-processor, which took as input a relocatable
> linked image) and code in m45.s was needed.
>
>   https://gunkies.org/wiki/Upgrading_UNIX_Sixth_Edition
>   https://gunkies.org/wiki/UNIX_V6_memory_layout
>
> The code in m45.s to handle split I+D in the kernel:
>
>   https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/conf/m45.s
>
> starts at 'start:' and is adequately commented to tell you what it's doing
> when it plays around with kernel memory.
>
>
>
>     > From: Will Senn
>
>     > with I/D, you can use 64k for I and 64k for D. Was that it, or were
>     > there other tricks to get even more allocated
>
> I have this vague memory that someone (Berkeley, I think?) added support
> for
> automatic code overlays in user processes. The programmer had to decide
> which
> modules went in which overlays, but after that it was all automagic. There
> was a 4xx code allocated to them.
>
> I think the support for that (in e.g. the linker) was somehow involved with
> the use of overlays in the kernel, but I don't know the details (nothing
> after V6 is at all interesting to me).
>

V7 had a number of patches for MENLO_LINKER or MENLO_OVERLAY that Berkeley
integrated into the tree, but I'm not sure they wrote it. Their hacks were
usually UCB_something...

Warner

    > didn't the 11 max out at 256k)?
>
> You need to distinguish between i) the amount of memory the machine could
> handle, and ii) the amount of memory that running code could 'see' at any
> instant. The latter was always either 64KB, or 64KB+64KB (with split I+D
> turned on, on CPUs which supported it).
>
> The former, it's complicated. Mostly, on UNIBUS only machines, it was
> 256KB.
> (Although there was the Able ENABLE:
>
>   https://gunkies.org/wiki/Able_ENABLE
>
> which added an Extended UNIBUS, and could take them up to 4MB.) The -11/70,
> as mentioned, had a Main Memory Bus, and could handle up to 4MB. The -11/44
> had an Extended UNIBUS, and could also handle up to 4MB (but only after the
> MS11-P became available; there were only 4 main memory slots in the
> backplane, and MS11-M cards were only 256KB.) On QBUS achines, after the
> KB11-A (Revision A), which only suppported 256 KB, all later revisions and
> CPUs could also handle up to 4MB.
>
>         Noel
>

[-- Attachment #2: Type: text/html, Size: 5787 bytes --]

[TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)

[Noel Chiappa]

    > From: Clem Cole

    > first two subsystems for the 11 that ran out of text space were indeed
    > vi and Pascal subsystems 

Those were at Berkeley. We've established that S-I&D were in V6 when it was
released in May, 1975 - so my question is 'what was Bell doing in 1975 that
needed more than 64KB?'

The kernel, yeah, it could definitely use S-I&D on a larger system
(especially when you remember that stock V6 didn't play any tricks with
overlays, and also dedicated one segment - the correct term, used in the 1972
-11/45 processor manual - to the user structure, and one to the I/O page,
limiting the non-S-I&D kernel to 48KB). But what user commands?


It happens that I have a complete dump of one of the MIT systems, so I had a
look to see what _we_ were running S-I&D on. Here's the list from /bin (for
some reason that machine doesn't have a /usr/bin):

  a68
  a86
  c86
  emacs
  lisp
  ndd
  send
  teco

The lisp wasn't a serious use; I think the only thing we ever used it for was
'doctor'. So, two editors, a couple of language tools, an email tool (not
sure why that one got it - maybe for creating large outgoing messages). (The
ndd is probably to allow the biggest possible buffers.)

Nothing in /etc, and in /lib, just lint1 and lint2 (lint, AFAICT, post-dates
V6). Not a lot.


So now I'm really curious what Bell was using S-I&D for. (If I weren't lazy,
I'd pull the V6 distro - which is only available as RK images, and individual
files, alas - and look in /bin and everywhere and see if I can find anything.
I suspect not, though.)

Anyone have any guesses/suggestions? Maybe some custom applications?

	Noel

[TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

On Thu, Aug 3, 2023 at 6:54 PM Clem Cole <clemc@ccc.com> wrote:

>
> ᐧ
>    Adding features and thinking less about what functionality was really
> needed started to get lost [so now we have Gnu - but I digress].
>

And a Good Thing Too.  I hate to think how many thousands of times in the
last few decades I have written "awk '{if (m < length) m = length} END
{print m}'" (and wondering for a moment if it's "length" or "len") until
someone mentioned "wc -L" to me just the other day.  Arrgh.

[-- Attachment #2: Type: text/html, Size: 1572 bytes --]

[TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 5645 bytes --]

I probably should add one more thing...  RT11 and RSX, and in particular
the DEC FTN compiler, supported thunks and overlays - i.e. larger-sized
programs before UNIX did.  IIRC, they needed them because by then the FTN
subsystem needed overlays to run itself. So .. assuming my memory is
correct, this was the reason why Fred rewrote the V7 code, and DEC pushed
it out as part of the v7m release.  Ken's original overlay support code was
not sufficient for the DEC language tools.

I don't remember if Ultrix-11 or v7m for that matter, ultimately got the
FTN compiler.  That said, Paul W might remember as he did the linker work
for Ultrix moving the VMS linker to Ultrix to support the 'Technical
Languages Group' (TLG ).  Utrix-32 certainly did get FTN I think a couple
of other of the RSX and RSTS languages, but my memory of Fred's work was to
support overlays in V7 so it could support it.  This was all during the
Unix wars inside of DEC.  Fred was part of the 'Telephone Industries Group'
(TIG) in MRK.
ᐧ

On Thu, Aug 3, 2023 at 6:54 PM Clem Cole <clemc@ccc.com> wrote:

>
> ᐧ
> below... [and I meant to answer the second ½ of your question before]
>
> On Thu, Aug 3, 2023 at 6:09 PM Will Senn <will.senn@gmail.com> wrote:
>
>> Clem,
>>
>> Oh, so... Without I/D, you're stuck with 64k max per process, with I/D,
>> you can use 64k for I and 64k for D.
>>
> Exactly but ... more in a minute.
>
>
>
>
>> Was that it, or were there other tricks to get even more allocated
>> (didn't the 11 max out at 256k)?
>>
> Different issues... the MMU on the 40 class and the 45/55 allows 256K [18
> bits], the MMU for the 70 class is 4M [22 bits], Unibus I/O controllers
> had 18 bits of address and RH70 controllers could support 22 bits of
> extended addresses - see the processor and peripheral handbooks for details
> [or I can explain offline].
>
> What the PDP-11 books calls 'pages' are 64-byte segments.  So the MMU is
> set up to allow the processor to address 64K or 64KI/64KD at the time,
> depending on if you have the I/D hardware, and the MMU is set up as to
> which 'pages' are being addressed.
>
> But you could overlay things ... [0405 files] with 'thunks'.
>
> So to allow a process (or the kernel) to have more than 64K, overlays can
> be loaded into memory and since the total physical space memory space is
> either 18 or 22 bits, if the kernel supports overlays - processes could get
> bigger [which is part of your first question].
> V7 was when 0405 [text only] overlays were added.   With DEC's release of
> v7m - Fred Cantor rewrote the overlay code and they became more general
> [and that would go into 2.9BSD].
>
> So the programmer needs to decide what you wanted to put into what
> overlay.   For processes, the kernel can swap out segments and replace them
> as needed.   The key is that link needs to generate near/far style calls
> and it can be a PITA.  If you want to access a routine that is not
> currently mapped into memory, the 'thunk' needs to ask the OS to switch it.
> Great thought of what was going to be stored where.
>
>
>
>
>>
>> The kernel could be compiled either with, or without separate I/D. The
>> only reason not to is if you didn't have more then 64k or were there other
>> reasons?
>>
> Well by V6, UNIX needed at least 64K of physical memory and it was really
> slow with anything less than 256K.   For the kernel, using I/D allowed the
> kernel to grow more easily.  By the time of trying to cram networking into
> it, running on anything less than an 11/44 was pretty hard.
>
> That said, Able made an alternate MMU called the ENABLE that allow 4M of
> memory on a Unibus system.  It worked at a cache/bus repeater.  So you set
> the internal MMU to point to it and then use its MMU.   Very cool and a
> soft spot for me. I ran an 11/60 [which is 40 class] with 2M of memory in
> Teklabs with the first Enable board.
>
> For whatever its worth, even with 4M the kernel had started to become a
> problem for V7 on an 11/70.  Data buffers eat a lot of memory.
>
>>
>> So, besides the kernel what apps tended to be split? If I remember
>> correctly, vi was one, pascal another?
>>
> Anything that started to get big ;-)
>
> Ppeople ran out of data space and text space from 64K fairly fast.   With
> the 32-bit Vax, the UNIX Small is Beautiful thinking started to fall away.
>  Rob has an excellent paper -> "cat -v considered harmful"   BSD UNIX, and
> the Vaxen greatly fueled that.   Adding features and thinking less about
> what functionality was really needed started to get lost [so now we have
> Gnu - but I digress].  Werner and the BSD 2.9 folks are to be commended for
> what they did with so few resources.   They moved things back from the Vax
> by using the overlays, but if you were to have any semblance of
> performance, you need the overlays to stay resident so you need that full
> 4M of memory.
>
> As for this specific question first two subsystems for the 11 that ran out
> of text space were indeed vi and Pascal subsystems (Joy having had his hand
> in both, BTW).  But they were hardly the only ones once the genie was out
> of the bottle.   Data space quickly became the real issue.  People really
> wanted larger heaps in particular.   In fact, by the 1990s, I knew of few
> programs that run out of 32-bit worth of text space, but many that
> started to run out of 32-bits of data space -> hence Alpha.   But BTW:
> DEC took a performance hit originally, and there was a huge discussion at
> the time if 64-bits was really needed.
> ᐧ
>

[-- Attachment #2: Type: text/html, Size: 11229 bytes --]

[TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)

[Steve Simon]

not quite split i and d but i do have a memory of some code which could run in three parts as overlays.

this could have been through exec’ing the next overlay with an appropriate argv and a pipe or file of data, or, perhaps there was some kernel support for overlays in early unix.

anyone seen evidence of this?

sadly i cannot remember where i saw it, i want to say it was a versatex printer driver but i am pretty sure that is rubbish.

-Steve

[TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)

[Dave Horsfall]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

On Thu, 3 Aug 2023, Clem Cole wrote:

> For whatever its worth, even with 4M the kernel had started to become a 
> problem for V7 on an 11/70.  Data buffers eat a lot of memory.

We at UNSW had a kludge for that; the global symbol "b" (similar to "u") 
was mapped by KISA5 into the current buffer header.  Having dozens of 
buffers on a 40-class machine was really something...

-- Dave

[TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 4384 bytes --]

ᐧ
below... [and I meant to answer the second ½ of your question before]

On Thu, Aug 3, 2023 at 6:09 PM Will Senn <will.senn@gmail.com> wrote:

> Clem,
>
> Oh, so... Without I/D, you're stuck with 64k max per process, with I/D,
> you can use 64k for I and 64k for D.
>
Exactly but ... more in a minute.




> Was that it, or were there other tricks to get even more allocated (didn't
> the 11 max out at 256k)?
>
Different issues... the MMU on the 40 class and the 45/55 allows 256K [18
bits], the MMU for the 70 class is 4M [22 bits], Unibus I/O controllers had
18 bits of address and RH70 controllers could support 22 bits of extended
addresses - see the processor and peripheral handbooks for details [or I
can explain offline].

What the PDP-11 books calls 'pages' are 64-byte segments.  So the MMU is
set up to allow the processor to address 64K or 64KI/64KD at the time,
depending on if you have the I/D hardware, and the MMU is set up as to
which 'pages' are being addressed.

But you could overlay things ... [0405 files] with 'thunks'.

So to allow a process (or the kernel) to have more than 64K, overlays can
be loaded into memory and since the total physical space memory space is
either 18 or 22 bits, if the kernel supports overlays - processes could get
bigger [which is part of your first question].
V7 was when 0405 [text only] overlays were added.   With DEC's release of
v7m - Fred Cantor rewrote the overlay code and they became more general
[and that would go into 2.9BSD].

So the programmer needs to decide what you wanted to put into what
overlay.   For processes, the kernel can swap out segments and replace them
as needed.   The key is that link needs to generate near/far style calls
and it can be a PITA.  If you want to access a routine that is not
currently mapped into memory, the 'thunk' needs to ask the OS to switch it.
Great thought of what was going to be stored where.




>
> The kernel could be compiled either with, or without separate I/D. The
> only reason not to is if you didn't have more then 64k or were there other
> reasons?
>
Well by V6, UNIX needed at least 64K of physical memory and it was really
slow with anything less than 256K.   For the kernel, using I/D allowed the
kernel to grow more easily.  By the time of trying to cram networking into
it, running on anything less than an 11/44 was pretty hard.

That said, Able made an alternate MMU called the ENABLE that allow 4M of
memory on a Unibus system.  It worked at a cache/bus repeater.  So you set
the internal MMU to point to it and then use its MMU.   Very cool and a
soft spot for me. I ran an 11/60 [which is 40 class] with 2M of memory in
Teklabs with the first Enable board.

For whatever its worth, even with 4M the kernel had started to become a
problem for V7 on an 11/70.  Data buffers eat a lot of memory.

>
> So, besides the kernel what apps tended to be split? If I remember
> correctly, vi was one, pascal another?
>
Anything that started to get big ;-)

Ppeople ran out of data space and text space from 64K fairly fast.   With
the 32-bit Vax, the UNIX Small is Beautiful thinking started to fall away.
 Rob has an excellent paper -> "cat -v considered harmful"   BSD UNIX, and
the Vaxen greatly fueled that.   Adding features and thinking less about
what functionality was really needed started to get lost [so now we have
Gnu - but I digress].  Werner and the BSD 2.9 folks are to be commended for
what they did with so few resources.   They moved things back from the Vax
by using the overlays, but if you were to have any semblance of
performance, you need the overlays to stay resident so you need that full
4M of memory.

As for this specific question first two subsystems for the 11 that ran out
of text space were indeed vi and Pascal subsystems (Joy having had his hand
in both, BTW).  But they were hardly the only ones once the genie was out
of the bottle.   Data space quickly became the real issue.  People really
wanted larger heaps in particular.   In fact, by the 1990s, I knew of few
programs that run out of 32-bit worth of text space, but many that started
to run out of 32-bits of data space -> hence Alpha.   But BTW:  DEC took a
performance hit originally, and there was a huge discussion at the time if
64-bits was really needed.
ᐧ

[-- Attachment #2: Type: text/html, Size: 9286 bytes --]

[TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)

[Kenneth Goodwin]

[-- Attachment #1: Type: text/plain, Size: 2985 bytes --]

Having worked on the v6 kernel on the
11/70 it was split on that version on that hardware.

On Thu, Aug 3, 2023, 5:10 PM Ronald Natalie <ron@ronnatalie.com> wrote:

> Having cut my UNIX teeth on the JHU 11/45, I can tell you very much that
> it did have split I/D.    V6 supported split I/D for user mode programs.
> The kernel originally wasn’t split I/D.   Version 7, if I’m recalling
> properly, did run the kernel split I/D on the 45 and 70.
>
>
>
> ------ Original Message ------
> From "Kenneth Goodwin" <kennethgoodwin56@gmail.com>
> To "Will Senn" <will.senn@gmail.com>
> Cc "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
> Date 8/3/23, 5:05:31 PM
> Subject [TUHS] Re: Split addressing (I/D) space (inspired by the death of
> the python... thread)
>
> At the risk of exposing my ignorance and thus being events long long ago
> in history....
> And my mind now old and feeble...
>
> 😆 🤣
>
> 1.  I don't think the 11/45 had split I & d.
> But I could be wrong.
> That did not appear until the 11/70
> And was in the later generation 11/44 several years later.
>
> 2. The kernel determined it by MMU type and managed it solely. The
> assembler and loader always built the binary object file as the three
> sections - instructions,  data and bss spaces so loading an object file
> could be done on any platform.
> Programmers generally did not worry about the underlying hardware
>
> 3. I don't recall if a systype style system call was available in v7 to
> give you a machine type to switch off of.
>
> With something like that you could determine memory availability hard
> limits on the DATA/bss side if you needed to.
>
> But that was also easily determined by a allocation failure in malloc/sbrk
> with an out of memory error.
>
> If you really needed to know availability,  you could have a start up
> subroutine that would loop trying to malloc ever decreasing memory sizes
> until success and until out of available memory error.
> Then release it all back via free(). Or manage it internally.
>
> As I recall however vaguely,  there was an attempt to split the kernel
> into two pieces. One running in kernel mode and one running in supervisor
> mode in order to double the amount of available  instruction and data
> spaces for the operating system. I recall playing around with what was
> there trying to get it to work right.
> I was trying to support over 200 users on a pdp 11/70 at the time running
> a massive insurance database system.
>
> On Thu, Aug 3, 2023, 4:35 PM Will Senn <will.senn@gmail.com> wrote:
>
>> Does unix (v7) know about the PDP-11 45's split I/D space through
>> configuration or is it convention and programmer's responsibility to
>> know and manage what's actually available?
>>
>> Will
>>
>> On 8/3/23 12:00, Rich Salz wrote:
>> > What, we all need something to kick now that we've beaten sendmail?
>> > How about something unix, ideally a decade old?
>>
>>

[-- Attachment #2: Type: text/html, Size: 4704 bytes --]

[TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)

[Will Senn]

[-- Attachment #1: Type: text/plain, Size: 2572 bytes --]

Clem,

Oh, so... Without I/D, you're stuck with 64k max per process, with I/D, 
you can use 64k for I and 64k for D. Was that it, or were there other 
tricks to get even more allocated (didn't the 11 max out at 256k)?

The kernel could be compiled either with, or without separate I/D. The 
only reason not to is if you didn't have more then 64k or were there 
other reasons?

So, besides the kernel what apps tended to be split? If I remember 
correctly, vi was one, pascal another?

Thanks!

Will

On 8/3/23 16:44, Clem Cole wrote:
> Will its a C Compiler switch (-i) and create 411 files instead of 407.
> I like to refer to it as the 17th address bit.
>
> I was first brought out with the 11/45 (which was SSI/MSI TTL), and 
> the biggest differences between it and the 11/40.  They were both 
> early 1970s and both of these processors were multiple boards. By 
> 1976, the 780 has started and that sucked off most of the HW folks.  
>  A new hire in 1976, Jeff Mitchell supposedly had a bet with Bill 
> Strecker that he could implement an 11 on a single"hex high" CPU board 
> if he got rid of the lights and switches.  He ran out of room to 
> implement seperate I/D, so it became an 11/40 class [and it has an 
> 8008-1 that runs the front panel].
>
> The 11/70 came out between the 11/45 and the 34 and had a number of 
> the STAR folks on it it original but it was also multiple boards.   It 
> was not until 11/44 that DEC was able to make a hex height 
> implementation of the 11 that managed to cram a full 11/70 into that 
> system.   The later J-11 chip set took things beyond the 11/70.
>
> If you look at the conf directory in the sys sources for V6, you see 
> m40.s and m45.s - but if you look at the link line of sys/run the 45 
> does not have -i; but if you look in sys/sys1.c you'll see the in the 
> routine getxfile the support for 0407/0411/0405/0410 files for user mode.
>
> If you look at the conf directory in the sys sources for V7, you see 
> mch.s and m45.s  its common and the makefile adds -i
>
> ᐧ
>
> On Thu, Aug 3, 2023 at 4:35 PM Will Senn <will.senn@gmail.com> wrote:
>
>     Does unix (v7) know about the PDP-11 45's split I/D space through
>     configuration or is it convention and programmer's responsibility to
>     know and manage what's actually available?
>
>     Will
>
>     On 8/3/23 12:00, Rich Salz wrote:
>     > What, we all need something to kick now that we've beaten sendmail?
>     > How about something unix, ideally a decade old?
>

[-- Attachment #2: Type: text/html, Size: 5408 bytes --]

[TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)

[Noel Chiappa]

    > From: Will Senn

    > Does unix (v7) know about the PDP-11 45's split I/D space through
    > configuration or is it convention and programmer's responsibility to
    > know and manage what's actually available?

There are two different cases: i) support of split I+D in the kernel, and
ii) support of split I+D in  user processes. Both arrived with V6; the
V5 source:

 https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/conf/mch.s
 https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/ken/main.c

(former for kernel; later for users) shows no sign of it.


    > From: Kenneth Goodwin <kennethgoodwin56@gmail.com>

    > 1.  I don't think the 11/45 had split I & d.
    > But I could be wrong.
    > That did not appear until the 11/70

You are wrong.

The chief differences between the KB11-A&-D of the -11/45 and the -B&-C of
the -11/70 were i) the latter had a cache, and ii) the latter used the 32-bit
wide Main Memory Bus, which also allowed up to 4 Mbytes of main memory.
Detail here:

  https://gunkies.org/wiki/PDP-11/70

along with a couple of lesser differences.


    > From: "Ronald Natalie"

    > with only 8 segment registers combined for code, data, and stack

I think you meant for code, data, and user block.

    > The 55 (just a tweaked 45)

The /50 and /55 had the identical KB11-A&-D of the /45; the difference was
that they came pre-configured with Fastbus memory.

    > In addition the 23/24/J-11 and those derived processors did.

No; the F-11 processors did not support I&D, the J-11 did.


	Noel

[TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]

Will its a C Compiler switch (-i) and create 411 files instead of 407.
I like to refer to it as the 17th address bit.

I was first brought out with the 11/45 (which was SSI/MSI TTL), and the
biggest differences between it and the 11/40.  They were both early 1970s
and both of these processors were multiple boards. By 1976, the 780 has
started and that sucked off most of the HW folks.   A new hire in 1976,
Jeff Mitchell supposedly had a bet with Bill Strecker that he could
implement an 11 on a single"hex high" CPU board if he got rid of the lights
and switches.  He ran out of room to implement seperate I/D, so it became
an 11/40 class [and it has an 8008-1 that runs the front panel].

The 11/70 came out between the 11/45 and the 34 and had a number of
the STAR folks on it it original but it was also multiple boards.   It was
not until 11/44 that DEC was able to make a hex height implementation of
the 11 that managed to cram a full 11/70 into that system.   The later J-11
chip set took things beyond the 11/70.

If you look at the conf directory in the sys sources for V6, you see m40.s
and m45.s - but if you look at the link line of sys/run the 45 does not
have -i; but if you look in sys/sys1.c you'll see the in the routine
getxfile the support for 0407/0411/0405/0410 files for user mode.

If you look at the conf directory in the sys sources for V7, you see mch.s
and m45.s  its common and the makefile adds -i

ᐧ

On Thu, Aug 3, 2023 at 4:35 PM Will Senn <will.senn@gmail.com> wrote:

> Does unix (v7) know about the PDP-11 45's split I/D space through
> configuration or is it convention and programmer's responsibility to
> know and manage what's actually available?
>
> Will
>
> On 8/3/23 12:00, Rich Salz wrote:
> > What, we all need something to kick now that we've beaten sendmail?
> > How about something unix, ideally a decade old?
>
>

[-- Attachment #2: Type: text/html, Size: 3422 bytes --]

[TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)

[Ronald Natalie]

[-- Attachment #1: Type: text/plain, Size: 4236 bytes --]

In fact, it was TCP (mbuf windowing) that killed the non split-I/D 
systems in our installation.    We were already using kernel overlays, 
but with only 8 segment registers combined for code, data, and stack, we 
just ran out of registers.     By then the VAXEN were coming along.  I 
recycled the 11/34’s etc… into LOS/C Internet routers.

The 55 (just a tweaked 45) and later the 44 also had it.   In addition 
the 23/24/J-11 and those derived processors did.


------ Original Message ------
From "Warner Losh" <imp@bsdimp.com>
To "Ronald Natalie" <ron@ronnatalie.com>
Cc "Kenneth Goodwin" <kennethgoodwin56@gmail.com>; "Will Senn" 
<will.senn@gmail.com>; "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
Date 8/3/23, 5:16:25 PM
Subject Re: [TUHS] Re: Split addressing (I/D) space (inspired by the 
death of the python... thread)

>2BSD also did split I&D in the kernel (as well as run TCP in supervisor 
>mode to get another I/D space). A lot of the overlays was done in the 
>linker, but it wasn't completely automated.
>I had to tweak the overlay tables a little as I did the 2.11pl0 work 
>since the early stuff wasn't exactly careful about distributing the 
>hacks to the makefile to make it happen...
>
>Warner
>
>On Thu, Aug 3, 2023 at 3:10 PM Ronald Natalie <ron@ronnatalie.com> 
>wrote:
>>Having cut my UNIX teeth on the JHU 11/45, I can tell you very much 
>>that it did have split I/D.    V6 supported split I/D for user mode 
>>programs.   The kernel originally wasn’t split I/D.   Version 7, if 
>>I’m recalling properly, did run the kernel split I/D on the 45 and 70.
>>
>>
>>
>>------ Original Message ------
>>From "Kenneth Goodwin" <kennethgoodwin56@gmail.com>
>>To "Will Senn" <will.senn@gmail.com>
>>Cc "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
>>Date 8/3/23, 5:05:31 PM
>>Subject [TUHS] Re: Split addressing (I/D) space (inspired by the death 
>>of the python... thread)
>>
>>>At the risk of exposing my ignorance and thus being events long long 
>>>ago in history....
>>>And my mind now old and feeble...
>>>
>>>😆 🤣
>>>
>>>1.  I don't think the 11/45 had split I & d.
>>>But I could be wrong.
>>>That did not appear until the 11/70
>>>And was in the later generation 11/44 several years later.
>>>
>>>2. The kernel determined it by MMU type and managed it solely. The 
>>>assembler and loader always built the binary object file as the three 
>>>sections - instructions,  data and bss spaces so loading an object 
>>>file could be done on any platform.
>>>Programmers generally did not worry about the underlying hardware
>>>
>>>3. I don't recall if a systype style system call was available in v7 
>>>to give you a machine type to switch off of.
>>>
>>>With something like that you could determine memory availability hard 
>>>limits on the DATA/bss side if you needed to.
>>>
>>>But that was also easily determined by a allocation failure in 
>>>malloc/sbrk with an out of memory error.
>>>
>>>If you really needed to know availability,  you could have a start up 
>>>subroutine that would loop trying to malloc ever decreasing memory 
>>>sizes until success and until out of available memory error.
>>>Then release it all back via free(). Or manage it internally.
>>>
>>>As I recall however vaguely,  there was an attempt to split the 
>>>kernel into two pieces. One running in kernel mode and one running in 
>>>supervisor mode in order to double the amount of available  
>>>instruction and data spaces for the operating system. I recall 
>>>playing around with what was there trying to get it to work right.
>>>I was trying to support over 200 users on a pdp 11/70 at the time 
>>>running a massive insurance database system.
>>>
>>>On Thu, Aug 3, 2023, 4:35 PM Will Senn <will.senn@gmail.com> wrote:
>>>>Does unix (v7) know about the PDP-11 45's split I/D space through
>>>>configuration or is it convention and programmer's responsibility to
>>>>know and manage what's actually available?
>>>>
>>>>Will
>>>>
>>>>On 8/3/23 12:00, Rich Salz wrote:
>>>> > What, we all need something to kick now that we've beaten 
>>>>sendmail?
>>>> > How about something unix, ideally a decade old?
>>>>

[-- Attachment #2: Type: text/html, Size: 7172 bytes --]

[TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 3278 bytes --]

2BSD also did split I&D in the kernel (as well as run TCP in supervisor
mode to get another I/D space). A lot of the overlays was done in the
linker, but it wasn't completely automated.
I had to tweak the overlay tables a little as I did the 2.11pl0 work since
the early stuff wasn't exactly careful about distributing the hacks to the
makefile to make it happen...

Warner

On Thu, Aug 3, 2023 at 3:10 PM Ronald Natalie <ron@ronnatalie.com> wrote:

> Having cut my UNIX teeth on the JHU 11/45, I can tell you very much that
> it did have split I/D.    V6 supported split I/D for user mode programs.
> The kernel originally wasn’t split I/D.   Version 7, if I’m recalling
> properly, did run the kernel split I/D on the 45 and 70.
>
>
>
> ------ Original Message ------
> From "Kenneth Goodwin" <kennethgoodwin56@gmail.com>
> To "Will Senn" <will.senn@gmail.com>
> Cc "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
> Date 8/3/23, 5:05:31 PM
> Subject [TUHS] Re: Split addressing (I/D) space (inspired by the death of
> the python... thread)
>
> At the risk of exposing my ignorance and thus being events long long ago
> in history....
> And my mind now old and feeble...
>
> 😆 🤣
>
> 1.  I don't think the 11/45 had split I & d.
> But I could be wrong.
> That did not appear until the 11/70
> And was in the later generation 11/44 several years later.
>
> 2. The kernel determined it by MMU type and managed it solely. The
> assembler and loader always built the binary object file as the three
> sections - instructions,  data and bss spaces so loading an object file
> could be done on any platform.
> Programmers generally did not worry about the underlying hardware
>
> 3. I don't recall if a systype style system call was available in v7 to
> give you a machine type to switch off of.
>
> With something like that you could determine memory availability hard
> limits on the DATA/bss side if you needed to.
>
> But that was also easily determined by a allocation failure in malloc/sbrk
> with an out of memory error.
>
> If you really needed to know availability,  you could have a start up
> subroutine that would loop trying to malloc ever decreasing memory sizes
> until success and until out of available memory error.
> Then release it all back via free(). Or manage it internally.
>
> As I recall however vaguely,  there was an attempt to split the kernel
> into two pieces. One running in kernel mode and one running in supervisor
> mode in order to double the amount of available  instruction and data
> spaces for the operating system. I recall playing around with what was
> there trying to get it to work right.
> I was trying to support over 200 users on a pdp 11/70 at the time running
> a massive insurance database system.
>
> On Thu, Aug 3, 2023, 4:35 PM Will Senn <will.senn@gmail.com> wrote:
>
>> Does unix (v7) know about the PDP-11 45's split I/D space through
>> configuration or is it convention and programmer's responsibility to
>> know and manage what's actually available?
>>
>> Will
>>
>> On 8/3/23 12:00, Rich Salz wrote:
>> > What, we all need something to kick now that we've beaten sendmail?
>> > How about something unix, ideally a decade old?
>>
>>

[-- Attachment #2: Type: text/html, Size: 4995 bytes --]

[TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)

[Ronald Natalie]

[-- Attachment #1: Type: text/plain, Size: 2765 bytes --]

Having cut my UNIX teeth on the JHU 11/45, I can tell you very much that 
it did have split I/D.    V6 supported split I/D for user mode programs. 
   The kernel originally wasn’t split I/D.   Version 7, if I’m recalling 
properly, did run the kernel split I/D on the 45 and 70.



------ Original Message ------
From "Kenneth Goodwin" <kennethgoodwin56@gmail.com>
To "Will Senn" <will.senn@gmail.com>
Cc "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
Date 8/3/23, 5:05:31 PM
Subject [TUHS] Re: Split addressing (I/D) space (inspired by the death 
of the python... thread)

>At the risk of exposing my ignorance and thus being events long long 
>ago in history....
>And my mind now old and feeble...
>
>😆 🤣
>
>1.  I don't think the 11/45 had split I & d.
>But I could be wrong.
>That did not appear until the 11/70
>And was in the later generation 11/44 several years later.
>
>2. The kernel determined it by MMU type and managed it solely. The 
>assembler and loader always built the binary object file as the three 
>sections - instructions,  data and bss spaces so loading an object file 
>could be done on any platform.
>Programmers generally did not worry about the underlying hardware
>
>3. I don't recall if a systype style system call was available in v7 to 
>give you a machine type to switch off of.
>
>With something like that you could determine memory availability hard 
>limits on the DATA/bss side if you needed to.
>
>But that was also easily determined by a allocation failure in 
>malloc/sbrk with an out of memory error.
>
>If you really needed to know availability,  you could have a start up 
>subroutine that would loop trying to malloc ever decreasing memory 
>sizes until success and until out of available memory error.
>Then release it all back via free(). Or manage it internally.
>
>As I recall however vaguely,  there was an attempt to split the kernel 
>into two pieces. One running in kernel mode and one running in 
>supervisor mode in order to double the amount of available  instruction 
>and data spaces for the operating system. I recall playing around with 
>what was there trying to get it to work right.
>I was trying to support over 200 users on a pdp 11/70 at the time 
>running a massive insurance database system.
>
>On Thu, Aug 3, 2023, 4:35 PM Will Senn <will.senn@gmail.com> wrote:
>>Does unix (v7) know about the PDP-11 45's split I/D space through
>>configuration or is it convention and programmer's responsibility to
>>know and manage what's actually available?
>>
>>Will
>>
>>On 8/3/23 12:00, Rich Salz wrote:
>> > What, we all need something to kick now that we've beaten sendmail?
>> > How about something unix, ideally a decade old?
>>

[-- Attachment #2: Type: text/html, Size: 4845 bytes --]

[TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)

[Ronald Natalie]

Both V6 and V7 used split I/D on the 45 and 70 where it as available.    
  You had to specify that you wanted it in your build, the choices were 
the 407 flagged. a.out, which had a single text/data/bss space 
(unspilt).    410 which still ran in one address space, but put the text 
in read only segments so they could be shared.   411 ran the executable 
in split I and D space.

The original use of the “sticky” bit in the inode mode indicated that a 
410 or 411 program text would be held in swap.

-Ron


------ Original Message ------
From "Will Senn" <will.senn@gmail.com>
To tuhs@tuhs.org
Date 8/3/23, 4:35:09 PM
Subject [TUHS] Split addressing (I/D) space (inspired by the death of 
the python... thread)

>Does unix (v7) know about the PDP-11 45's split I/D space through configuration or is it convention and programmer's responsibility to know and manage what's actually available?
>
>Will
>
>On 8/3/23 12:00, Rich Salz wrote:
>>What, we all need something to kick now that we've beaten sendmail?  How about something unix, ideally a decade old?
>

[TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)

[Kenneth Goodwin]

[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]

At the risk of exposing my ignorance and thus being events long long ago in
history....
And my mind now old and feeble...

😆 🤣

1.  I don't think the 11/45 had split I & d.
But I could be wrong.
That did not appear until the 11/70
And was in the later generation 11/44 several years later.

2. The kernel determined it by MMU type and managed it solely. The
assembler and loader always built the binary object file as the three
sections - instructions,  data and bss spaces so loading an object file
could be done on any platform.
Programmers generally did not worry about the underlying hardware

3. I don't recall if a systype style system call was available in v7 to
give you a machine type to switch off of.

With something like that you could determine memory availability hard
limits on the DATA/bss side if you needed to.

But that was also easily determined by a allocation failure in malloc/sbrk
with an out of memory error.

If you really needed to know availability,  you could have a start up
subroutine that would loop trying to malloc ever decreasing memory sizes
until success and until out of available memory error.
Then release it all back via free(). Or manage it internally.

As I recall however vaguely,  there was an attempt to split the kernel into
two pieces. One running in kernel mode and one running in supervisor mode
in order to double the amount of available  instruction and data spaces for
the operating system. I recall playing around with what was there trying to
get it to work right.
I was trying to support over 200 users on a pdp 11/70 at the time running a
massive insurance database system.

On Thu, Aug 3, 2023, 4:35 PM Will Senn <will.senn@gmail.com> wrote:

> Does unix (v7) know about the PDP-11 45's split I/D space through
> configuration or is it convention and programmer's responsibility to
> know and manage what's actually available?
>
> Will
>
> On 8/3/23 12:00, Rich Salz wrote:
> > What, we all need something to kick now that we've beaten sendmail?
> > How about something unix, ideally a decade old?
>
>

[-- Attachment #2: Type: text/html, Size: 2958 bytes --]