🚀 go-pugleaf

In article <110@wldrdg.UUCP> tony@wldrdg.UUCP (Tony Andrews) writes:
>My favorite propaganda is the stuff Intel
>puts out about segmentation.
>
>I hated segmentation long before I ever worked with the 68K. I've been
>doing kernel level work (SVR2 & SVR3) on the 286 for the last year, and
>I hate it. And that has nothing to do with Motorola.

I think your opinions on segmentation are just opinions, and very
poorly informed ones at that. Certainly small segments are painful but
big enough segments are very useful. After all, if you really love
linear addressing so much, just declare a large segment and be done
with it. (this assumes segments which can support 32 bit addresses)

-- 
 The VT220 keyboard is an <iS<o standard. That means the French can
 hate it as well as the Americans.

 <phil <ngai +1 408 749 5720
 <u<uC<p: <[ucbvax,decwrl,ihnp4,allegra<]!amdcad!phil
 AR<pA<; amdcad!phil@decwrl.dec.com

In article <110@wldrdg.UUCP> tony@wldrdg.UUCP (Tony Andrews) writes:
>Oh perfect. What a nice objective start we've gotten off to. Anyone
>who doesn't like intel products must be a 68K FANATIC and will tend
>to spout Motorola PROPAGANDA. My favorite propaganda is the stuff Intel
>puts out about segmentation.

   I think this sort of thing belongs somewhere else.  As I understand it,
this group isn't here to talk about whether the general architecture of
the Intel processor family is good or bad; that can go on endlessly in
several other groups.  I hope this is going to be a forum for much more
detailed technical discussion about the details of the architecture and
its development.  If it degenerates into religious wars, the technical
people (myself included) will quickly unsubscribe.  Please don't ruin
the newsgroup because you don't like the architecture.

-- 
    Dan Frank
    uucp: ... uwvax!prairie!dan
    arpa: dan%caseus@spool.wisc.edu

In article <13772@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes:
:In article <110@wldrdg.UUCP> tony@wldrdg.UUCP (Tony Andrews) writes:
:>My favorite propaganda is the stuff Intel
:>puts out about segmentation.
:I think your opinions on segmentation are just opinions, and very
:poorly informed ones at that. Certainly small segments are painful but
:big enough segments are very useful. After all, if you really love
:linear addressing so much, just declare a large segment and be done
:with it. (this assumes segments which can support 32 bit addresses)

Sure sounds like AMD has made some significant enhancements to the
80286.  Please send me two of these miracle chips for my PC-AT's ASAP,
I've run out of time trying to get all this neat net.sources software to
fit within segments on the Intel 80286 chips in my machines.  Also, a
compatible 287 chip would be nice. 

P.S.: What S/W changes are needed to correct the segment size? 

... radio!
	-Mr. Spock

Expires:11/21/86



Maybe all newsgroups dealing with CPU chips should be moderated to prevent
flaming wars.  

In article <111@wldrdg.UUCP> tony@wldrdg.UUCP (Tony Andrews) writes:
>Okay, so I over-generalized slightly. The 386 is a reasonable chip
>and will support UNIX quite nicely. But the SVR3 port to the 386
>just makes all UNIX processes small model, which is effectively
>the same address space as a 32032 or 68K. The segmentation isn't
>really used other than to support 286 binaries.

I assume when you say small model, you mean things fit in one segment.
Really, that's how things should be. Trying to manage objects too big
to fit in one segment by using multiple segments is clearly a losing
proposition. Now, Intel advertises the 80286 as a 16 bit machine.
People who try to use it as a 32 bit machine really shouldn't complain
when they find out it doesn't work well.

It does sound like SVR3 doesn't use segments for anything useful. I
don't think there is any version of Unix which does. But a long time
ago, an operating system named Multics did some neat things with
segments. That Unix doesn't use them doesn't mean segments are a
useless idea.

>Of course, my opinions are just opinions and so are yours and Intel's.
>That's not the point. I just couldn't stand such a blatant example
>of the pot calling the kettle black.

Well, I think a lot of so called Intel propaganda has actually been
people putting words in Intel's mouth. I've never seen Intel refer to
the 80286 as a 32 bit machine. All the flames I have seen have been
from people trying to use it as such. Now who's fault is that?

-- 
 The distance from the North end of Vietnam to the South end is about
 the same as the distance from New York to Florida.

 Phil Ngai +1 408 749 5720
 UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil
 ARPA: amdcad!phil@decwrl.dec.com

In article <13801@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes:
>don't think there is any version of Unix which does. But a long time
>ago, an operating system named Multics did some neat things with
>segments. That Unix doesn't use them doesn't mean segments are a
>useless idea.

OK, all you intel hackers, here's a question for you.  This will tell
me very quickly if I want to ever deal with segments or not.  By the
way, my question could be quickly answered if I had a 386 reference
in front of me, but I don't so here goes:

Suppose I use your bloody segments.  I put the stack in one, the data 
in another, and the text in another.  [ Oops, forgot context, this is
the layout for the memory management of Unix process, but could be 
any OS that multi tasks. ]  My questions are

1) How does virtual to physical (page => frame) mapping occur?  Are there
   seperate page tables for each segment, or what?  (I know, dumb
   question).

2) OK, a better question:  suppose my process forks (spawns a child)
   and I would like to set things up as follows:

   o  child gets personal copy of stack.

   o  child gets shared copy of text.

   o  child gets gets shared (with parent) copy of data addresses
      0x01ffff..0xffffff (for example).

   o  child gets personal copy of data addresses 0x1ffffff and above.

   In other words, I want to take the section of memory with virtual
   addresses 0x01ffff to 0xffffff and have that shared.  Can this be
   __easily__ done with the 386 memory management?  Seems like it 
   would be a nice thing to support.  Don't forget, there may be 
   valid data addresses both above and below the segment in question;
   you can't split it into two, have to go to three chunks.

3) And yet another nifty question: can I make the new non-shared
   data segments be copy-on-write?  

4) How about using a segment to catch stack overflow?  Dynamically altering
   segment size?  From user mode? Supervisor mode?  After or during
   allocation?  

Finally, how much is this is handled by software and how much is supported 
by the hardware (directly).

So, waddya say, intel?
-- 
Larry McVoy 	        mcvoy@rsch.wisc.edu, 
      		        {seismo, topaz, harvard, ihnp4, etc}!uwvax!mcvoy

"They're coming soon!  Quad-stated guru-gates!"

In article <2971@rsch.WISC.EDU> mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) writes:
>OK, all you intel hackers, here's a question for you.  This will tell
>me very quickly if I want to ever deal with segments or not.
>
>Suppose I use your bloody segments.  I put the stack in one, the data 
>in another, and the text in another.  [ Oops, forgot context, this is
>the layout for the memory management of Unix process, but could be 
>any OS that multi tasks. ]  My questions are
>
>1) How does virtual to physical (page => frame) mapping occur?  Are there
>   seperate page tables for each segment, or what?  (I know, dumb
>   question).
The memory management is two stage: First you map segmented virtual address
to linear virtual address.  Then you run through the page tables to change
the linear virtual address to a linear real address.  The segmentation and
the paging are somewhat orthogonal.  Normally a segment will begin on a page
boundary, but I don't think that's required.  (Can't be exactly sure, my 386
manual is right here, either.)

>2) OK, a better question:  suppose my process forks (spawns a child)
>   and I would like to set things up as follows:
>
>   o  child gets personal copy of stack.
>
>   o  child gets shared copy of text.
>
>   o  child gets gets shared (with parent) copy of data addresses
>      0x01ffff..0xffffff (for example).
>
>   o  child gets personal copy of data addresses 0x1ffffff and above.
>
>   In other words, I want to take the section of memory with virtual
>   addresses 0x01ffff to 0xffffff and have that shared.  Can this be
>   __easily__ done with the 386 memory management?  Seems like it 
>   would be a nice thing to support.  Don't forget, there may be 
>   valid data addresses both above and below the segment in question;
>   you can't split it into two, have to go to three chunks.
How this is done in a Unix(R) environment isn't completely clear.  C doesn't
provide simple mechanisms for saying "These variables are in segment N".
However, if you can work that, this can be done.  (It might be easier in some
other languages.  I haven't seen any 386 compilers or linkers yet.)

The proper way of thinking of this is: 

o Child gets a personal copy of the stack segment.

o Child gets a descriptor pointing to a shared copy of the text segments.

o The child gets descriptors pointing to the data segments, with appropriate
bits set for copy-on-write on most of them.  One of them (call it segment 4)
is marked simply to be shared (no copy-on-write).  (Here's the big win for 
segments, BTW.  Rather than marking many page table entries, only a few
segment table entries needed to be marked.)

Once again, how you indicate that this should occur in C is unclear.  If the
memory region contains static variables, you have to be able to tell C or 
the linker to put them in segment n.  If the memory region is dynamicly 
allocated, I expect that there will be a system/library call for allocating
memory in a new segment.  Of course, this would require the availablility
of 48-bit pointers.  (The same problem occurs in linear-address Unix; you
have to be able to indicate which variables are in the specified address
range.)

Note also that I haven't exactly done what you want--instead of addresses
0x01ffff to 0xffffff, what we are talking about here are addresses
0x0100000000 to 0x01ffffffff.  (Or whatever segment number is chosen.)

>3) And yet another nifty question: can I make the new non-shared
>   data segments be copy-on-write?  
As I said, this is easy, and requires a good deal less work than in a paged
machine.  (Unfortunately, there's no bit reserved in the segment entry for
this, so there will need to be a shadow table.  Won't be the first time.)

>4) How about using a segment to catch stack overflow?  Dynamically altering
>   segment size?  From user mode? Supervisor mode?  After or during
>   allocation?  
Stacks will normally be expand-downward segments.  (Similar to P1 space
on a Vax.)  A segment-violation interrupt occurs on stack overflow.  The
interrupt handler runs with its own stack, and can allocate new memory.
It can even move the stack in linear-address memory, if need be.  This can
certainly be done for user stack segments; system stack segments may need
to be nailed down (made non-pagable and fixed size).

>Finally, how much is this is handled by software and how much is supported 
>by the hardware (directly).
As usual, normal cases and detection of unusual cases are handled in hardware,
and handling the unusual cases is done in software.  I think that this
is really what you'd prefer.

>So, waddya say, intel?

I hope I've shown that several interesting things can be done with segments
(when the segment size is not a problem).  I hope that a Unix port is done
which allows these things.  (I suspect that several Unix ports will be done
which use segments in a totally degenerate manner, treating the 386 as a
separate I/D, linear address space machine.  All of the things you want can
be done that way, too, in a conventional Unix manner.)

>-- 
>Larry McVoy 	        mcvoy@rsch.wisc.edu, 
>      		        {seismo, topaz, harvard, ihnp4, etc}!uwvax!mcvoy

P.S.  I found my 386 book, so I really do think this is right.
-- 
Craig Jackson
UUCP: {harvard!axiom,linus!axiom,ll-xn}!drilex!dricej
BIX:  cjackson

phil@amdcad.UUCP (Phil Ngai) writes:
> It does sound like SVR3 doesn't use segments for anything useful. I
> don't think there is any version of Unix which does. But a long time
> ago, an operating system named Multics did some neat things with
> segments. That Unix doesn't use them doesn't mean segments are a
> useless idea.

It's hard to do within UNIX. I've thought about the problem a lot.
If you take the approach of putting each data structure in its own
segment then you wind up doing a lot of segment register loads which
are slow. The two new segment registers in the 386 will help
alleviate this problem.

A couple of days ago I ran a quick benchmark to see how much a small
model program would slow down when compiled large model. I used the
UNIX "od" command and measured a performance decrease of 35%. I ran
the same experiment with "sum" and it slowed down by 50%. In both
cases I used an optimizer which eliminates redundant segment loads
for a single symbol, but not for different symbols. So this corresponds
fairly well to your example of putting each data structure in its own
segment. The advantages you discussed may be worth the performance
penalty, but there is a penalty.

Another problem with making better use of segments in UNIX is that
the brk and sbrk primitives don't work out very well. You really
need to be able to have a finer level of control over the allocation
and deallocation of segments.

> Well, I think a lot of so called Intel propaganda has actually been
> people putting words in Intel's mouth. I've never seen Intel refer to
> the 80286 as a 32 bit machine. All the flames I have seen have been
> from people trying to use it as such. Now who's fault is that?

Intel representatives (yes, actual employees) have repeatedly stated
that the 286 is a good UNIX machine, in comparison to 32-bit processors
like the 68K and 32032. (And if you only support small model, and really
use it as a 16 bit machine, that's actually true.) This may not be a
globally accepted view within Intel, but at least some Intel people
have marketed the 286 as a 32-bit machine. Granted, this was all a
couple of years ago. I'm sure their strategy has changed now that the
386 is around.

Tony Andrews
...!ihnp4!onecom!wldrdg!tony
Wildridge Consulting, Inc.
Boulder, CO

In article <2971@rsch.WISC.EDU> mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) writes:
>2) OK, a better question:  suppose my process forks (spawns a child) ...
>   In other words, I want to take the section of memory with virtual
>   addresses 0x01ffff to 0xffffff and have that shared.  Can this be
>   __easily__ done with the 386 memory management?  Seems like it 
>   would be a nice thing to support.  Don't forget, there may be 
>   valid data addresses both above and below the segment in question;
>   you can't split it into two, have to go to three chunks.

This is a biased question.  It askes "how do I use segments to share a portion
of my linear address space?"  The answer is that with segments you don't share
portions of your linear address space, you share collections of data contained
entirely within segments.  You would place the data you want to share in its
own segment and share the segment instead of carefully placing your data at a
known location in your linear address space and then sharing those locations.

Consider, suppose I want to share addresses 0x10010 through 0x10020, but MUST
NOT share 0x10000 through 0x1000F or 0x10021 through 0x20000.  How am I going
to do this in a paged virtual address space, assuming pages are 1 Kb large.
Don't scream "unfair", because it is the same question in a different guise.
-- 
  Lawrence Crowl		716-275-5766	University of Rochester
			crowl@rochester.arpa	Computer Science Department
 ...!{allegra,decvax,seismo}!rochester!crowl	Rochester, New York,  14627

In article <2971@rsch.WISC.EDU> mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) writes:
>1) How does virtual to physical (page => frame) mapping occur?  Are there
>   seperate page tables for each segment, or what?  (I know, dumb
>   question).

No, there isn't a page table for each segment.  The segment and offset combine
to create a 32-bit "linear address," which is then translated by the paging
hardware into a 32-bit physical address.

>2) OK, a better question:  suppose my process forks (spawns a child)
>   and I would like to set things up as follows:
>
>   o  child gets personal copy of stack.
>
>   o  child gets shared copy of text.
>
>   o  child gets gets shared (with parent) copy of data addresses
>      0x01ffff..0xffffff (for example).
>
>   o  child gets personal copy of data addresses 0x1ffffff and above.
>
>   In other words, I want to take the section of memory with virtual
>   addresses 0x01ffff to 0xffffff and have that shared.  Can this be
>   __easily__ done with the 386 memory management?  Seems like it 
>   would be a nice thing to support.  Don't forget, there may be 
>   valid data addresses both above and below the segment in question;
>   you can't split it into two, have to go to three chunks.

Maybe I'm dense, but I don't quite see the problem.  Aside from having to
create a new fork call that can do all you ask.  If you look at the 386 as
a straight paged machine, which it can easily be, then it isn't any different
than any other paged machine.  If you look at it as a segmented/paged machine,
they you need to rethink your terms.  Instead of looking at addresses as
offsets in a single linear address space, you'd look at them as segments
and offsets into the segments.  Instead of sharing address ranges, you'd
work sharing segments.  If you want to have a non-shared segment spanned
by a shared segment in linear space, you can do it, but it doesn't really
buy you much except for having two different ways of addressing the same
memory location.  But then again, if you are working with an eye to
segmentation, you aren't working with offsets in a single linear address
space, but offsets into multiple segments.

>3) And yet another nifty question: can I make the new non-shared
>   data segments be copy-on-write?  

sure, just make them read-only, and any attempt to write to the segment
will trigger a segmentation fault, and the os will have to copy the contents
of the old segment to a new area in linear address space, and point up
the segment table to the new segment (to the programmer, the segment number
he uses to address the segment will remain the same).

>4) How about using a segment to catch stack overflow?  Dynamically altering
>   segment size?  From user mode? Supervisor mode?  After or during
>   allocation?  

sure, why not?  Segments are variably sized and these sizes can be changed
if a segment fault occurs and the offending instruction restarted.

>Finally, how much is this is handled by software and how much is supported 
>by the hardware (directly).

All the memory checks are handled in hardware.  What happens when one is
detected needs to be handled in software, just like any other addressing
fault (e.g., page faults in a normal system).

I think part of the problem is that segments are user visible selections
of the address space.  c doesn't provide the facility to change segments,
to put various data structures in different segments, or anything like that.
It also likes to be able to address static data structures in the same
linear address space as dynamic data structures.  It would be a lot easier
to work with segmentation if it wasn't something that had to be hidden
from the user because the programming language doesn't support it.  With
the 386 you have the option of not using segmentation because the straight
linear address size of the machine is 4 GBytes.  But just because it is
difficult to use with c doesn't mean that there isn't anything out there
that could use it.  I could think of "enhancements" to c that would make
segmentation programmer visible in the language, and adding os calls
to return to the user new segments to play with, but it is something that
is very specific to segmented or segmented/paged machines, so you couldn't
run it too easily on your vax or sun or whatever, so it probably wouldn't
be done.
-- 
The above views are personal.

The primary reason innumeracy is so pernicious is the ease with which numbers
are invoked to bludgeon the innumerate into dumb acquiescence.
			- John Allen Paulos

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

   If you don't have per-segment page tables, then you don't have hardware
support for copy-on-write of pages, only segments.  I consider this a
pretty serious deficiency.


-- 
    Dan Frank
    uucp: ... uwvax!prairie!dan
    arpa: dan%caseus@spool.wisc.edu

In article <113@wldrdg.UUCP> tony@wldrdg.UUCP (Tony Andrews) writes:
>Intel representatives (yes, actual employees) have repeatedly stated
>that the 286 is a good UNIX machine, in comparison to 32-bit processors
>like the 68K and 32032. (And if you only support small model, and really
>use it as a 16 bit machine, that's actually true.)

Well, it's no worse than a PDP-11. But I'm not going to defend such
claims. I have actually heard people at my company say similar things.
But they were marketing types, not engineers.

With regard to the high cost of reloading segment registers, maybe
what is needed is the equivalent of what TLBs do in the paging world.

-- 
 The distance from the North end of Vietnam to the South end is about
 the same as the distance from New York to Florida.

 Phil Ngai +1 408 749 5720
 UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil
 ARPA: amdcad!phil@decwrl.dec.com

In article <362@prairie.UUCP> dan@prairie.UUCP (Daniel M. Frank) writes:
>   If you don't have per-segment page tables, then you don't have hardware
>support for copy-on-write of pages, only segments.  I consider this a
>pretty serious deficiency.

now this I don't understand.  The segmentation translates the segment/
offset pair into a 32-bit offset into linear address space while the
paging hardware translates the 32-bit linear address into a 32-bit
physical address.  Maybe I'm dense, but I don't see why you need to
have a page table per segment to support copy on write pages using
this scheme...
-- 
The above views are personal.

The primary reason innumeracy is so pernicious is the ease with which numbers
are invoked to bludgeon the innumerate into dumb acquiescence.
			- John Allen Paulos

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

> OK, all you intel hackers, here's a question for you.  This will tell
> me very quickly if I want to ever deal with segments or not.
> 
> 1) How does virtual to physical (page => frame) mapping occur?  Are there
>    seperate page tables for each segment, or what?  (I know, dumb
>    question).

Right. Dumb question. It does the right thing.

> 
> 2) OK, a better question:  suppose my process forks (spawns a child)
>    and I would like to set things up as follows:
> 
>    o  child gets personal copy of stack.
> 
>    o  child gets shared copy of text.
> 
>    o  child gets gets shared (with parent) copy of data addresses
>       0x01ffff..0xffffff (for example).
> 
>    o  child gets personal copy of data addresses 0x1ffffff and above.
> 
>    In other words, I want to take the section of memory with virtual
>    addresses 0x01ffff to 0xffffff and have that shared.  Can this be
>    __easily__ done with the 386 memory management?  Seems like it 
>    would be a nice thing to support.  Don't forget, there may be 
>    valid data addresses both above and below the segment in question;
>    you can't split it into two, have to go to three chunks.

All easy, though the sharing naturally has to happen in page-sized
increments.

> 
> 3) And yet another nifty question: can I make the new non-shared
>    data segments be copy-on-write?  

Yes, write protect the pages and use software to figure out what to do.
Straightforward. There is also a user-use bit out there to play with in the
PTE.

> 
> 4) How about using a segment to catch stack overflow?  Dynamically altering
>    segment size?  From user mode? Supervisor mode?  After or during
>    allocation?  

There is a stack segment size notion.

> 
>    If you don't have per-segment page tables, then you don't have hardware
> support for copy-on-write of pages, only segments.  I consider this a
> pretty serious deficiency.
> 

Oh, crap. Read the manual before you betray your ignorance and save all of
us the trouble of correcting it. You can do write protection on a
page-by-page basis. Since all of the segments end up mapped into a flat
address space, you protect them/unprotect them at that level, including,
possibly, sharing a page between two segments.

The *pages* can be write protected.