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

[Warner Losh]

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 at 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 at gmail.com>
> To "Will Senn" <will.senn at gmail.com>
> Cc "The Eunuchs Hysterical Society" <tuhs at 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 at 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?
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20230803/126bab08/attachment.htm>