Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!rex!uflorida!gatech!mcnc!rti!dg-rtp!siberia!hamilton From: hamilton@siberia.rtp.dg.com (Eric Hamilton) Newsgroups: comp.sys.m88k Subject: Re: Proposed Change to memctl() Message-ID: <1990Dec22.035201.20759@dg-rtp.dg.com> Date: 22 Dec 90 03:52:01 GMT References: Sender: usenet@dg-rtp.dg.com (Usenet Administration) Reply-To: hamilton@siberia.rtp.dg.com (Eric Hamilton) Organization: Data General Corporation, Research Triangle Park, NC Lines: 35 In article , jkf@Franz.COM (Sean Foderaro) writes: |> |> I support your request for the trap to sychronize a region of the |> address space. However unless the memctl change I propose is |> passed, there isn't a need for the trap since it will still be |> illegal to have read-write-execute pages. |> I suspect that our postings have crossed in the mail.... I've addressed this point in a "Read/write/execute Proposal" which I posted to comp.sys.m88k. And, yes, I agree that the memctl() change or something similiar is needed *as well as* the cache synchronizing trap. |> The primary reason the 88open people gave for the current state of |> memctl() is that multiprocessor systems couldn't handle the memctl() |> change I proposed. As you are familiar with 88k multiprocesor systems |> can you tell me if this is true? Is this anything (that you can |> reveal) about future versions of the 88k chipset that will make this |> true? Could you imagine anyone building there own caching system |> (not the 88200) that support a paging version of Unix yet which |> can't support the memctl() change? |> There has to have been a misunderstanding somewhere along the line. It is true that, in general, the cache synchronization trap must act on all processors' caches, but that certainly doesn't make it unimplementable. In fact, the cache synchronization trap does exactly the same thing that the kernel must do, in general, when paging in any executable pages (assuming that the instruction caches don't snoop - a good assumption). This one is technically feasible and not even especially difficult, on uniprocessor and multiprocessor systems, with all 88000s that I am aware of. I cannot imagine designing a caching subsystem for which this would not be the case.