🚀 go-pugleaf

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