[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(a)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(a)gmail.com> >To "Will Senn" <will.senn(a)gmail.com> >Cc "The Eunuchs Hysterical Society" <tuhs(a)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(a)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? >>>