Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!styx!ames!oliveb!intelca!mipos3!kds From: kds@mipos3.UUCP (Ken Shoemaker ~) Newsgroups: comp.sys.intel Subject: Re: comp.sys.intel Message-ID: <265@mipos3.UUCP> Date: Thu, 20-Nov-86 16:43:39 EST Article-I.D.: mipos3.265 Posted: Thu Nov 20 16:43:39 1986 Date-Received: Fri, 21-Nov-86 02:02:32 EST References: <110@wldrdg.UUCP> <13772@amdcad.UUCP> <111@wldrdg.UUCP> <13801@amdcad.UUCP> <2971@rsch.WISC.EDU> Reply-To: kds@mipos3.UUCP (Ken Shoemaker ~) Distribution: na Organization: Intel, Santa Clara, CA Lines: 91 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