🚀 go-pugleaf

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