Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-unix!sri-spam!ames!oliveb!intelca!mipos3!kds
From: kds@mipos3.UUCP (Ken Shoemaker ~)
Newsgroups: comp.sys.intel,comp.lang.c
Subject: Re: segments and Unix
Message-ID: <260@mipos3.UUCP>
Date: Wed, 19-Nov-86 03:11:17 EST
Article-I.D.: mipos3.260
Posted: Wed Nov 19 03:11:17 1986
Date-Received: Wed, 19-Nov-86 22:29:54 EST
References: <13802@amdcad.UUCP> <9400@sun.uucp>
Reply-To: kds@mipos3.UUCP (Ken Shoemaker ~)
Organization: Intel, Santa Clara, CA
Lines: 63
Xref: mnetor comp.sys.intel:30 comp.lang.c:100

I'm sorry, but I have to take exception to some of the points raised here:
In article <9400@sun.uucp> david@sun.uUCp (David DiGiacomo) writes:
>
>No, for four reasons:
>
> - It is very expensive to expand pointers to hold a reasonably large 
>   (16 bit?) segment number field.

very expensive?  They are already at least 32-bits wide!  Besides, I
thought that the whole idea of the 32-bit processors was that you got
to talk to lots of memory...

>
> - Other things being equal, address translation is slowed considerably 
>   by segment bounds checking.

it really depends on how you do it.  In the 386 the segment bounds checking
is integrated into the pipeline and happens in parallel with other things
going on, so it really doesn't add to the processing time of the instruction.

> - Non-uniform pointers lead to additional software complexity and cause 
>   severe problems when porting code from traditional systems.

I'll agree with this one...

> - You can easily accomplish what you want to do in a pure paged
>   system.  Just decide that you are going to use an arbitrary number of
>   pointer bits for the "segment" number and load your page tables
>   accordingly.  The only difference is that segment granularity is one
>   page, but that shouldn't matter for the debugging application you
>   mention.

This implies some amount of control by the application program of what
kinds of accesses are allowed to various parts of its virtual memory
space.  Maybe I'm wrong, but if you have a segmented system, I'd think
that it would be easier for the os to manage a request for a segment
of some size than it would be for the os to assign the attributes
for a certain page, and then to maintain them for you.  In addition,
I'd think that it would be easier from a programmer standpoint to
keep track of a single segment number than it would be for the
programmer to keep track of an area of memory in a linear space.
Imagine being able to have calls to set the brk location in one
of any number of segments.  Not very Unix-like, difficult
to do with c, and only applicable to processors that support
segmentation, but?  You've also got a problem with the concept
of setting page table attributes and porting tools from any generic
architecture in that page tables are not at all consistent from
one architecture to another, or even between systems using the
same architecture.  And you can expect that page table sizes will
change as memory sizes increase.  There are very good reasons to
hide this kind of memory management from the user in that it is
pretty closely tied to the hardware of the system.  With segments,
you are dealing with a level of abstraction that isn't quite as
close to the hardware, and isn't as likely to change as the system
"ages."  But then, what do I know...
-- 
The above views are personal.

I've seen the future, I can't afford it...

Ken Shoemaker, Microprocessor Design, Intel Corp., Santa Clara, California
uucp: ...{hplabs|decwrl|amdcad|qantel|pur-ee|scgvaxd|oliveb}!intelca!mipos3!kds
csnet/arpanet: kds@mipos3.intel.com