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" To "Ronald Natalie" Cc "Kenneth Goodwin" ; "Will Senn" ; "The Eunuchs Hysterical Society" 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 >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" >>To "Will Senn" >>Cc "The Eunuchs Hysterical Society" >>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 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? >>>>