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: Copy-on-write
Message-ID: <271@mipos3.UUCP>
Date: Mon, 24-Nov-86 16:15:35 EST
Article-I.D.: mipos3.271
Posted: Mon Nov 24 16:15:35 1986
Date-Received: Tue, 25-Nov-86 07:11:26 EST
References: <110@wldrdg.UUCP> <13772@amdcad.UUCP> <111@wldrdg.UUCP> <13801@amdcad.UUCP> <2971@rsch.WISC.EDU> <265@mipos3.UUCP> <362@prairie.24 Nov 86 21:15:35 GMT
Reply-To: kds@mipos3.UUCP (Ken Shoemaker ~)
Distribution: na
Organization: Intel, Santa Clara, CA
Lines: 21

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