According to Waldek Hebisch <antispam@fricas.org>:

Don?t confuse x86 segmentation with Multics/Burroughs segmentation.
The former was a pain in the bum, the latter was an elegant solution
to programs being bigger than available physical memory.

"Elegant" depends on point of view. Other people would call
it "wasteful". Multics segmentation worked well because there
was large number of large segments. But that had its costs:
general pointers were twice as large as on comparative non
segmented machine. For prgrams that just use arrays this is
not a problem, but if you have interesting dynamic data
structures you will have a lot of pointers. Pointers may be
hidden by langage machinery, but you still pay cost of them.

Nonetheless one of the reasons Multics died was that it ran out of
address bits. An 18 bit word offset was about a megabyte which wasn't
big enough, and kludges to try and spread larger data objects across
multiple segments are always ugly.

The 286 segment scheme always impressed me as deeply passive
aggressive. The low three bits of the segment number were status bits
so if you wanted to use bigger than 64K things, you had to do just as
much kludgy shifting as on the 8086. There was no good reason for
that, the bits would have worked equally well as the high three bits but
I get the impression the designers thought "that'll FORCE them to use
the segments the way we want them to.".

It also didn't help that loading a segment register was extremely
slow, and the hardware didn't even check for the fairly common case of
loading the same segment number that was already there.

Also, segmentation without paging causes memory fragmentation and the
operating system has to shuffle segments around to get contiguous free
space. That didn't help either. The 386 cheaped out by mapping all the segments into one paged address space rather than paging the segments
like Multics did, but by that time it was clear that segments were a
dead end.

x86 was born in/for penny pinching world and you see consequences
in the design.

My understanding was that 8086 was intended to be close enough to the 8085
to allow mechanical translation of assembler source, while still having
a path to the future. I agree the faux segments by shifting the segment
number was pretty gross, but I never saw any sort of address extension
to use bigger than 16 bit addresses in a 16 bit machine that wasn't.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

John Levine <johnl@taugh.com> writes:

According to Waldek Hebisch <antispam@fricas.org>:

Don?t confuse x86 segmentation with Multics/Burroughs segmentation.
The former was a pain in the bum, the latter was an elegant solution
to programs being bigger than available physical memory.

"Elegant" depends on point of view. Other people would call
it "wasteful". Multics segmentation worked well because there
was large number of large segments. But that had its costs:
general pointers were twice as large as on comparative non
segmented machine. For prgrams that just use arrays this is
not a problem, but if you have interesting dynamic data
structures you will have a lot of pointers. Pointers may be
hidden by langage machinery, but you still pay cost of them.

Nonetheless one of the reasons Multics died was that it ran out of
address bits. An 18 bit word offset was about a megabyte which wasn't
big enough, and kludges to try and spread larger data objects across
multiple segments are always ugly.

When I started at Burroughs, they had just started a project
to increase amount of memory that could be accessed by
an application on the medium systems (B3500) line. The
B3500 had a flat one million digit address space and
could run in 'control state' or 'normal state'. When the
base register had the value zero, the processor ran in
control state and privileged instructions were available,
otherwise the processor was is normal state and the
1md address space started at the privileged base register and
ended at the privileged limit register.

One goal of the project was to allow existing binary
executables to continue to run without changes.

The processor hardware at the time had enough
hardware registers to support eight simultaneous
base/limit pairs, so new firmware was developed to
treat one of the digits of the 8-digit index registers as
a base selection digit, allowing access to
eight 1MD memory areas per process at any one
time.

A set of memory areas was called an environment;
a special call instruction (VEN, Virtual Enter) was created
to call into an environment, or locally within an
environment.

Memory area 0 provided the stack, the index registers
and other common data and was replicated in every environment.

Memory area 1 contained the code. Instructions that referenced
code (e.g. branches) automatically used MA1.

Memory areas 2 through 7 were application dependent.

A task could have up to a million environments.

New instructions were developed to move data between
memory areas in different environments


<snip>

Also, segmentation without paging causes memory fragmentation and the >operating system has to shuffle segments around to get contiguous free
space.

Indeed. The MCP had code to "defragment" memory or it could roll-out
a task to drum/disk/pack to make space for another job.

That didn't help either. The 386 cheaped out by mapping all the
segments into one paged address space rather than paging the segments
like Multics did, but by that time it was clear that segments were a
dead end.

While the medium systems described above were all retired by 2010,
there are still large systems (B6800 descendents) running production
code in emulation on intel systems. Large systems was built around
segments from the start in the mid 1960s.


--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)