🚀 go-pugleaf

hammondr@sunroof.crd.ge.com (Richard A Hammond) writes:
| If I recall properly, Multics hardware couldn't address more than 2^18
| words(?) per segment.  While that was huge at the time, it isn't all
| that interesting now as an upper limit.  What, if anything, did the
| programmer do to handle files > 1 segment in length?

	Alas, this was badly handled in the first 9 or so releases...  The
	segment sizes were really 2^16 (words, I think! I remember
	discussion of leaving addressability to the byute in the design) and
	the maximum file size was something like 2^72 bits.

	The mechanism for doing large files was the so-called multi-segment
	file, which was really a directory containing more than one segment.
	Applications treating these as sequential constructs just opened
	them and read/write.  The segment manager looked after having
	multiple segments with the "same" name.  Applications doing random
	I/O (including one of mine) had a harder time, as the structure
	could be and occasionally was, manipulated directly by the idiot
	programmer. This was both hard and non-portable.

| This is not to say that memory mapped files are a "BAD IDEA", just
| that they have limits that must be considered by the programmer.

	The replacement, being worked on when I left, was the "extended
	object", which was a generalization of the file and contained the
	code for mapping very large segments into the address spaces in
	a programmer-independant manner: you said the equivalent of 
	stdio_$fseek(stream, offset, ptrname) and you were there

--dave (if you have limits, they should be 0, 1, or infinity) c-b


-- 
David Collier-Brown,  | davecb@yunexus, ...!yunexus!davecb or
72 Abitibi Ave.,      | {toronto area...}lethe!dave 
Willowdale, Ontario,  | Joyce C-B:
CANADA. 416-223-8968  |    He's so smart he's dumb.