Path: utzoo!attcan!uunet!cs.utexas.edu!asuvax!mcdphx!udc!dfields From: dfields@urbana.mcd.mot.com (David Fields) Newsgroups: comp.sys.m88k Subject: Re: m88200 cache flushes on DG Aviion Message-ID: <1448@urbana.mcd.mot.com> Date: 12 Dec 90 16:14:19 GMT References: <1199@dg.dg.com> <4322@photon.oakhill.UUCP> Sender: netnews@urbana.mcd.mot.com Organization: Motorola Computer Group, Urbana Design Center Lines: 52 In article pierson@encore.com (Dan L. Pierson) writes: >In article <4322@photon.oakhill.UUCP> jimk@oakhill.UUCP (Jim Klingshirn) writes: >> We periodically receive requests to add user level instructions >> to generate cache control operations. The justification generally >> is centered around data caches - for instance how can you force data >> out so that it is guaranteed to get out to the graphics frame buffer >> when the cache is in copyback mode. To date, the only justification >> I've heard for instruction cache control is to support self >> modifying code (including breakpoints). Assuming there are alternate >> ways to support breakpoints - should we worry about instruction cache >> control operations? > >Yes, any language system that incrementally compiles or dynamically >loads code then executes it needs to flush caches. Lisp is a good >example of the worst case here. Many Lisp systems: >Lisp is not the only language with this type of requirements, just a >good example. First, I'm not a chip designer nor do I work with dynamic compilation systems so ... I've got a few questions. I'll attempt to answer them as best as I can and see if anyone else can do a better job. I'm not going to consider having the instruction and data caches be coherent because then you would have to address the instruction pipeline and I believe that most of us would find that entirely too expensive. 1) What are the reasons to make cache flush operations priviledged? In a multi-processor system, a user could slow response times of other users a little easier than he could before. Are there any other reasons? Are there any security (i.e. Orange Book) issues? For example, does this make an unlimitable high badwidth covert channel? 2) What's the cost of the user level cache flush instruction? It seems as though it shouldn't effect cycle time since you have to provide this in supervisor mode anyway. Is this true? Are there any other costs? 3) What's the real performance penalty of not having one? It's more difficult for the implementors of the dynamic compilation system but from what I've heard many get around the problem by compiling and flushing in larger chunks to amortize the cost. Just like garbage collection. I seem to remember Andrew Klossner posting about someone doing this at Tek. Does anyone have any performance info that they could post? -- Dave Fields // Motorola MCD // uiucuxc!udc!dfields // dfields@urbana.mcd.mot.com