Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site spar.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!decwrl!spar!freeman
From: freeman@spar.UUCP (Jay Freeman)
Newsgroups: net.arch
Subject: Re: I like segmented architectures
Message-ID: <309@spar.UUCP>
Date: Mon, 10-Jun-85 12:35:03 EDT
Article-I.D.: spar.309
Posted: Mon Jun 10 12:35:03 1985
Date-Received: Sun, 16-Jun-85 07:13:52 EDT
References: <276@spar.UUCP> <5653@utzoo.UUCP> <291@spar.UUCP> <1031@peora.UUCP>
Reply-To: freeman@max.UUCP (Jay Freeman)
Organization: Schlumberger Palo Alto Research, CA
Lines: 47

[libation to line-eater]

In article <1031@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes:

> [a thoughtful article comparing Intel-style segmentation
>  with more traditional approaches to memory management -- JF]

>The 8086's way of handling segmentation is not like that of many more
>familiar machines, 68000 included.  [discussion of address-calculation by
>concatenation of bit-fields (traditional approach) versus shift-and-add
>(Intel approach) follows -- JF]

If shift-and-add segmentation were made transparent to the user, by putting
it in an inaccessible MMU, how would it then compare with the concatenation
technique?

>This is what the compiler writers have trouble with [...] deciding when
>you need to change the contents of the segmentation register becomes
>enormously difficult.
>
>And optimization is really the issue here.  A fully unoptimized 8086-family
>program would load the segmentation register before EVERY operand access.
>The task of the optimizer is to decide when it doesn't have to.
>
>And that is the basic problem.

Well put.  I had thought that flow-analysis was in fact state-of-the-art
for compilers (though admittedly still a thorny problem).  If not, there is
clearly a problem with all forms of messy addressing.

I view user-controlled segmentation more as a special kind of addressing
than a memory-management scheme (though it clearly can help with the latter).
I see it as providing support for abstract data types and object-oriented
programming, at a very low level -- you put your specialized object in its
own segment, and rely on the hardware to trap if you attempt to access it
incorrectly.  Or you put different instantiations of a particular flavor of
object in their own segments, and just change a segment register to get at
one instantiation instead of another.

Segments can be made much smaller than the typical page size of a more
traditional MMU.  Thus access rights to objects can be specified with much
higher resolution -- down to individual procedures and (small) data
structures.

And I need these tools:  It's so hard to do object-oriented programming in my
favorite languages -- '66 FORTRAN, COBOL and Tiny BASIC.  :-)
-- 
Jay Reynolds Freeman (Schlumberger Palo Alto Research)(canonical disclaimer)