Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!rex!rouge!ralph!elgamy!elg
From: elg@elgamy.RAIDERNET.COM (Eric Lee Green)
Newsgroups: comp.arch
Subject: Re: Segmented Architectures ( formerly Re: 48-bit computers)
Message-ID: <00670208556@elgamy.RAIDERNET.COM>
Date: 29 Mar 91 01:02:36 GMT
References: <1991Mar27.172325.10800@sj.nec.com>
Organization: Eric's Amiga 2000 @ Home
Lines: 77

From article <1991Mar27.172325.10800@sj.nec.com>, by koll@NECAM.tdd.sj.nec.com (Michael Goldman):
>       Why Segmented Architectures Are Wrong
>
> I could recite a litany of horror stories about how my segmented life was
> made intolerable by operating system bugs, application bugs, and compiler
> bugs ("- The Huge Model doesn't work in your version, but for $75 we'll

You're confusing Intel segments with "real" segments. Intel's basic problem
is that their segment size is tiny. A "C" programmer (and "C" compiler) should
not have to worry about segment size in most instances.


1) Shared libraries and other shared code. A shared library is a strange
   object. In a "flat" address space, you must either make it reside at a
   fixed address in EACH AND EVERY PROCESS, or you must specially write it
   with no, absolutely no, absolute references, so that it can reside at
   different locations in different processes. The latter may require a
   lot of special "smarts" on the part of the compiler and library writer.

    On a segmented machine, call the OS "ObtainLibPtr" call to map the
    library segment into your "object space". The first <n> words of the
    segment might be the jump table for library routines. Code can thus
    reside in different places in different processes, and no relocating or
    special non-absolute referencing modes need be employed.

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
re-allocating it somewhere else and possibly copying a whole lot of data.
You could re-write your code to use some other data structure, true, but
in many cases there's a decided speed disadvantage to doing that. Or you
could then decide to plunk your object into a part of the address space
where you HOPE the rest of the program's data won't go, but at best that's
a kludge, at worst you'll guess wrong.
    Segments represent an elegant and logical solution to this set of
problems.

3) Mapping shared objects into the address space.
    This can be done on a machine with a "flat" address space, of course.
But if you want to do 2) above, have a large shared object that shrinks and
grows (let's say, perhaps, you want to share an editor buffer between the
editor and compiler), you have problems. If the shared object contains
embedded addresses, e.g. it's a linked list or B-Tree or other such data
structure, you have even worse problems... basically, it can't be done, not
without mapping the object into the same addresses in each address space
(which has collision potential... what if some other desired object is also
mapped at that same address space?). The "solution", for flat address space
people, is simply not to do it, to use shared memory only as an IPC
mechanism rather than as a method of truly sharing objects.

The biggest obstacles confronting segmented architectures:
    1) Intel gave segments a bad name.
    2) "C" is set up to compile "flat" PDP-11-like code, and is not
the sort of object-oriented language that would map naturally onto a
segmented architecture.
    3) Operating systems. Current "merchant" operating systems such as Unix
are tied to "lowest common denominator" hardware, and do not have
provisions for segmentation. Proprietary operating systems are expensive
to design and build, and have the problem of attracting sufficient software
to make them commercially viable (unless you're DEC and you just came out
with VMS as the primary OS for the world's first "super-mini").
    4) Complexity. Segment tables add an additional level of complexity to
a MMU. The RISC folks, after stripping all the cruft out of their CPU's,
aren't likely to consider putting object-oriented cruft back into their
MMU's. After all, their business is Unix and "C", neither of which have any
provisions for handling segments.

Given the current predominance of Unix and "C", I don't see how
segmentation could become an identifying characteristic of any new
general-purpose computer architecture. This doesn't mean that segments are
a bad idea, though. It just means that it is not commercially viable, at
this time, under current conditions.

--
Eric Lee Green   (318) 984-1820  P.O. Box 92191  Lafayette, LA 70509
elg@elgamy.RAIDERNET.COM               uunet!mjbtn!raider!elgamy!elg
 Looking for a job... tips, leads appreciated... inquire within...