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