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

[Kenneth Goodwin]

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/aed2551e/attachment.htm>