John Levine <
jo...@taugh.com> writes:
>According to Scott Lurndal <
sl...@pacbell.net>:
>>Speaking as a Burroughs programmer who wrote portions of the MCP, I can't
>>agree with that. Our segmentation scheme was there simply
>>for backward compatability in the medium systems line.
>>
>>The large systems version lives on in Clearpath Libra for
>>backward compatability with applications built in the 1960s.
>>
>>There have been no new designs with segmentation for decades
>>and the effort to enhance the large systems
>>architecture and maintain compatability when E-mode was
>>added wasn't a simple exercise.
>
>I can believe it, but how much of that was because the segments were
>too small? My impression is that's what killed all the segmented
>architectures, and by the time you came up with a segment scheme with
>bigger addresses, you might as well just adopt a generic flat address
>and use all the free software that supports it.
Certainly segment _size_ was an important constraint. Before we
revamped the medium systems architecture, a task/job/process was
limited to 500 kilobytes of memory (1 million digits). The
segmentation scheme that we added, for backward compatability,
couldn't support more than a million digits without significant
changes to the instruction set (which had 6-digit address operands);
so segmentation was the only way to maintain backward compatability
and preserve the ability to execute 1965 binaries without performance
killing emulation.
Adding paging within a segment, to ameliorate the pain of memory
fragmentation wasn't really possible at the time.
>
>>>Oh, and Linux chose flat addressing because linux is a copy of Unix
>>>and Unix grew up on Vaxes with flat memory. It made sense only in that
>>>it made sense to copy the memory model along with everything else.
>>
>>Unix grew up on the PDP-11 with fixed segment sizes.
>
>I was there and not really. On the 11/45 and 11/70 you got 64K of
I was there using v6 on an 11/34. Granted, never had a chance
to use the 11/70, but heavily used the 11/780 (loved it!). Our
11/44 ran custom software acting as a terminal controller.
>instruction space and 64K of data space. The hardware divided each
>into eight 8K pages but they were too big to be useful so each segment
>was always contiguous and could be from 8K to 64K in 8K increments.
>When Berkeley moved BSD to the Vax we all moved there and didn't look
>back.
I played a bit with the 32-bit WE Unix on the /780 on weekends, but we
always ran VMS in production. The earliest versions of VMS
we were using still used some RSX-11 utilities running in
compatability mode. Never used BSD.
>The Vax's paging enabled shared libraries and mapped files and
>much larger programs on 4BSD. That's where all modern Unix
>and linux trace back to, even though some of them do so
>by merging the good bits of BSD into other varieties like
>System V.
We were working with AT&T/USL during the SVR4 development
when the BSD stuff was merged in. A large part of that was
user-level stuff, but it also included job-control and
iirc resource limit controls in the kernel itself.