Path: utzoo!attcan!telly!lethe!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!fernwood!franz!jkf From: jkf@Franz.COM (Sean Foderaro) Newsgroups: comp.sys.m88k Subject: Re: Proposed Change to memctl() Message-ID: Date: 19 Dec 90 17:22:58 GMT Sender: news@Franz.COM Organization: Franz Inc., Berkeley, CA Lines: 37 >> From: hamilton@dg-rtp.dg.com (Eric Hamilton) >> How about a new trap: >> r2 contains the base address >> r3 contains the length >> >> tb0 0,r0, >> Will cause the data and instruction caches for the specified region (between >> r2 and r2+r3-1, byte granular, no minimum length) to come into coherence, >> so that that region can be safely executed. 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. My immediate concern is getting this rather obvious memctl() flaw fixed in the spec and thus I proposed something with very little implementation cost. The 88open folks tell me that even this little change will have a hard time getting passed. So I'm concerned that if I start asking for more (like the trap you suggested), that it won't have a chance of getting passed. 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? -john foderaro franz inc.