Path: utzoo!utgpu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!davecb
From: davecb@yunexus.YorkU.CA (David Collier-Brown)
Newsgroups: comp.arch
Subject: Re: Segmented Architectures
Message-ID: <22203@yunexus.YorkU.CA>
Date: 2 Apr 91 01:53:23 GMT
References: <1991Mar27.172325.10800@sj.nec.com> <00670208556@elgamy.RAIDERNET.COM> <1655@spim.mips.COM>
Organization: York U. Computing Services
Lines: 44

In article <00670208556@elgamy.RAIDERNET.COM> elg@elgamy.RAIDERNET.COM (Eric Lee Green) writes:
| 2) Maintaining large objects that grow and shrink. In a sequential address
| space, often you can't "grow" an object because something else has been
| allocated in the addresses immediately afterwards. And thus you may end up

mash@mips.com (John Mashey) writes:
| Actually, I Don't think this quite right.  Consider the difference
| between a scheme that has X-bit segment numbers and Y-bit byte addresses
| within the segment, and compare with one that has an X+Y-bit flat address
| space.  In the first case, using typical designs, you get 2**X segments
| of size 2**Y, which usually means that objects are CONVENIENTLY
| 2**Y maximum size. the X+Y-bit flat address machine can simulate the same
| thing rather conveniently...

   Er, I'm going to attack this whole thread...

   I think the use of segments to describe any fixed size construct is
horribly wrong.  A segment, in its youth, was a name.  Your pre-multics
7090-clone assembler program had one or more code segments, an initialized
data segment and an uninitialized (``bss'') data segment.
   Multics tried to generalize these into a thing which could either have
its existance in core, pointed to by a descriptor, or on disk, pointed to by
a pathname. Alas, those segments had fixed maximum sizes.
   Unix returned us to the first model, and lost the elegant mapping to
files.
   Intel returned us to too-small fixed-size segments, possibly due to a too
literal translation of what they found in a Honeybun [did you notice the
rings and gates, bye the bye?]

   Bah, humbug (:-)).

   I think we need to avoid the term segment, unless we're really talking
about laying assembly code out in memory.  Do consider paging in files, with
the understanding that they may have to be relocated in order to grow and
shrink, but avoid segments like the plague: the word has stopped meaning
anything, save when talking about pie-shaped chunks of disk.

--dave
   
-- 
David Collier-Brown,  | davecb@Nexus.YorkU.CA | lethe!dave
72 Abitibi Ave.,      | 
Willowdale, Ontario,  | Even cannibals don't usually eat their
CANADA. 416-223-8968  | friends.