🚀 go-pugleaf

In article <89May7.001514edt.39763@neat.ai.toronto.edu> bradb@ai.toronto.edu (Brad Brown) writes:
>In article <1989May6.234007.23517@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>>In article <89May6.165030edt.10782@ephemeral.ai.toronto.edu> bradb@ai.toronto.edu (Brad Brown) writes:
>>>Unfortunately, a machine like this can't run C very well, 'cause C presupposes
>>>a flat, uniform memory space...
>>Untrue.  (Consider all the C compilers for the revolting 8086 and its ugly
>>descendants, which most definitely don't have a flat uniform memory space.)
>But consider how C is implemented on the 8086 and it's brethren:  You simulate
>a flat address space and give the programmer a bunch of different memory models
>so they can decide how big their flat space is.

Don't confuse Intel segmentation with segmentation in general.  On
8086-like processors, segments get in the way, and dealing with
multiple data segments and/or multiple code segments in one program
results in performance penalties.  The various memory models are
compromises so that programs that don't need the benefits of multiple
segments can avoid the performance problems.

Multics and Burroughs segments, however, don't get in the way in that
manner, unless you want to have a single object that doesn't fit in a
segment (in the case of Multics, the max size is 1MB).  All pointers
include a segment number, there aren't separate segment and offset
registers (i.e. a pointer register can address any location in
memory).  Unless a program cares about segments, it can ignore them.

C has been implemented on Multics, and the segmentation had no
affect on the implementation.

>  The point is that C wants to
>be able to point anywhere in memory, more or less, whereas really segmented
>machines like the Buroughs I was talking about get thier protection ability
>from having a segment for each (more or less) object in the system.

Why can't a segmented pointer point anywhere in memory?

I don't know about Burroughs software, but on Multics we don't assign
a segment to every object.  There's a segment for every command or
subroutine library, a stack segment for each ring, and some number of
heap segments for dynamic allocation.  In addition, when files are
mapped into the address space (which is the only way to access files)
they are assigned unique segments, and applications may allocate
temporary segments for data rather than allocating out of the heap
segment (this is generally done for performance reasons, as it can
reduce page faults by separating unrelated data).

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar