Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!mit-eddie!genrad!panda!enmasse!drilex!dricej From: dricej@drilex.UUCP (Craig Jackson) Newsgroups: comp.sys.intel Subject: Re: comp.sys.intel (really how to use segments) Message-ID: <190@drilex.UUCP> Date: Thu, 20-Nov-86 09:19:49 EST Article-I.D.: drilex.190 Posted: Thu Nov 20 09:19:49 1986 Date-Received: Thu, 20-Nov-86 23:14:04 EST References: <110@wldrdg.UUCP> <13772@amdcad.UUCP> <111@wldrdg.UUCP> <13801@amdcad.UUCP> <2971@rsch.WISC.EDU> Reply-To: dricej@drilex.UUCP (Craig Jackson) Distribution: na Organization: Data Resources/McGraw-Hill, Lexington, MA Lines: 107 Summary: No problem ... 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