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

["Ronald Natalie" <ron@ronnatalie.com>]

[-- 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 --]