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?