Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!hsdndev!husc6!encore!alan
From: alan@encore.encore.COM (Alan Langerman)
Newsgroups: comp.sys.m88k
Subject: Re: m88200 cache flushes on DG Aviion
Keywords: m88200 Aviion
Message-ID: <13521@encore.Encore.COM>
Date: 13 Dec 90 17:08:21 GMT
References: <2308@io.UUCP> <1199@dg.dg.com> <4322@photon.oakhill.UUCP>
Sender: news@Encore.COM
Reply-To: alan@encore.com
Organization: Encore Computer Corp.
Lines: 26

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?
|> 
|> 
|> Jim Klingshirn,
|> Motorola 88000 Design

Not only self-modified code, but other-modified code.  A process can
have its text mapped read/write by a second process, which in turn may
alter that text, possibly while the first process is running.  (We do
this on our MP systems, on which we have built a sophisticated
shared-memory debugger.)  So we need to be able to flush not only the
current processor's I-cache and pipe but also some OTHER processor's
I-cache and pipe.  (I'm not directly involved in this work, so I'm not
sure how we currently solve this problem.)

-----
Alan Langerman		(alan@encore.com)