[TUHS] Memory management in Dennis Ritchie's C Compiler

[Rob Gingell]

On 8/17/2020 12:27 PM, Noel Chiappa wrote:
>      > From: Jim Geist
> 
>      > When did mmap(2) come about?
> 
> Pretty sure it's a Berserkleyism. I think it came in with the VM stuff that
> DARPA mandated for VAX Unix (for the research project they funded).

[What follows verges on being COFF-ish].

mmap() is descended from TENEX's PMAP, which is a simplified descendant 
of the file/process memory integration provided by Multics. (Other 
antecedents I leave to more informed genealogists than I.)

A Multics process had an address space made up of segments (files) which 
were paged (vs. swapped). Segments were what programs dealt with, paging 
was done to manage the physical resources of the system.

TENEX simplified everything to pages, address spaces were composed by 
mapping pages of the address space to files. Programs operated on pages, 
which were also what the system used to manage memory. Files were 
described by page tables, address spaces were described by page tables, 
lots of symmetry around things of size 512 (9 bits) (page size, page 
table size, page-tables of page tables for long files). File size and 
file system system capacities were announced in pages. Very harmonious, 
but uniquely so.

Multics was most definitely not portable due to its unique hardware 
constraints (Intel's 432 being an exception). TENEX only required paging 
support but was not portable from PDP-10s which were not keeping up with 
the world's movement to computers that were increasingly 4-bits shy of a 
word (i.e., not 36 bits). Many more considerations apply but to keep it 
only verging on COFF-ish will stop there -- going deeper would be best 
done in person with tankards of ale.

TENEX systems were ARPA's workhorse systems in the 1970s, supporting 
numerous research programs and sites. The file/process memory 
integration was a valued capability among the community (though, 
honestly, it was one of these things everyone said should exist though 
few actually used directly). Even though DEC provided commercial support 
by adopting TENEX as TOPS-20 and selling 1000s of them (vs. the 10s of 
them made via BBN + PARC's MAXC), as the 70's progressed it was apparent 
that things were going to shift elsewhere. DEC was hesitant about 
further 36-bit development and UNIX's arrival provided an intellectual 
migration path for the community that commercial alternatives didn't. If 
only UNIX could just accumulate some of the capabilities expected in the 
ARPA world, like file/process memory integration (ironically, one of the 
Multics complexities from which UNIX had departed.)

mmap() is a simplified, portable form of PMAP. It was written into the 
specifications for ARPA via Bill Joy as Larry McVoy and Noel Chiappa 
noted. It existed only as a specification for quite a while. First 
implementations were as a device-driver level function for things like 
frame-buffers for use by window systems and perhaps for other devices 
I'm not remembering at the moment.

The general file/process memory integration aspect didn't happen prior 
to SunOS 4.0 though I seem to recall some special-case subsets being 
tried by other UNIX implementations and also more generally with Mach, I 
believe. The gestalt of file/process memory integration in 4.0 was very 
TENEX-like in how it was used in fork()/exec()/brk()/shared libraries. 
4.0 differed from TENEX in being portable, launched on heterogeneous 
hardware (VAX, 68010 (Sun-2's), 68020 (Sun-3's), 386 (386i), SPARC 
(Sun-4) all except the VAX being actively supported Sun products at the 
time), and a general-networking view of how coherency should work (vs. a 
clustered-network such as TOPS-20's CFS.)

(As a hysterical note, every release of (BSD-based) SunOS through 4.0 
was always ported to the VAX as a portability check. It also provied us 
utility as a convenient way to quickly check for "but it works on the 
VAX" problems with new things gotten from UCB. Prior to 4.0, given that 
the BSD-based implementation basically tried to mimic a VAX internally, 
that wasn't too bad. But the VAXectomy that occurred in 4.0 made that 
much more daunting, and so the 4.0 VAX port was a pretty half-hearted 
attempt and the last new task for the 11/750 that faded deeper and 
deeper into the back of the lab over time.)