Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!uunet!snorkelwacker.mit.edu!hsdndev!husc6!encore!pierson From: pierson@encore.com (Dan L. Pierson) Newsgroups: comp.sys.m88k Subject: Re: m88200 cache flushes on DG Aviion Message-ID: Date: 11 Dec 90 22:30:50 GMT References: <2308@io.UUCP> <1199@dg.dg.com> <4322@photon.oakhill.UUCP> Sender: news@Encore.COM Organization: Encore Computer Corporation Lines: 45 In-reply-to: jimk@oakhill.UUCP's message of 11 Dec 90 01:37:22 GMT 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: 1. Put compiled code (incrementally or loaded) into dynamic space. 2. Manage dynamic space with a copying garbage collector. This means that code may move between calls however the old code location will only be reused after the entire semi-space it's part of has been freed for reuse (there are less friendly GC algorithms...). 3. Loading a Lisp compiled file can consist of an arbitrary sequence of: load a bit, execute some of what you just loaded, load some more, etc. The i cache has to be cleaned as efficiently as possible in here. Lisp is not the only language with this type of requirements, just a good example. dan In real life: Dan Pierson, Encore Computer Corporation, Research UUCP: {talcott,linus,necis,decvax}!encore!pierson Internet: pierson@encore.com -- dan In real life: Dan Pierson, Encore Computer Corporation, Research UUCP: {talcott,linus,necis,decvax}!encore!pierson Internet: pierson@encore.com