Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!oakhill!jimk
From: jimk@oakhill.UUCP (Jim Klingshirn)
Newsgroups: comp.sys.m88k
Subject: Re: m88200 cache flushes on DG Aviion
Keywords: m88200 Aviion
Message-ID: <4322@photon.oakhill.UUCP>
Date: 11 Dec 90 01:37:22 GMT
References: <2308@io.UUCP> <1199@dg.dg.com>
Organization: Motorola Inc. Austin, Tx
Lines: 52

n article <2308@io.UUCP>, dbjag@io.UUCP (David Benjamin) writes:
|> Does anyone know of a good method for forcing a memory cache flush on
|> a Data General Aviion 300 series workstation.  Specifically, I would like
|> to request a specific line flush from the m88200 cache handling instructions.|> I'm not too keen on a full flush of both caches, as that would take too much |> time.
|> 
|> The reason is kind of hairy, but if you must know, it involves self-modifying|> code which seems to fail on the Aviion when the caches get out of sync.
|> There, glad you asked?
|> 
|> This brings up another question.  The code is apparently failing because
|> the contents of the two caches different values for the same address.
|> Why wasn't this state prevented by the "M-bus snooping" of the 88200's?
|> Perhaps my understanding of their function is warped.
|> 
|> Thanks in advance.
|> 
|> -- 
|> - Dave Benjamin                                                               -
|> - Interleaf                                                                   -
|> - ...!eddie.mit.EDU!ileaf!dbjag                                               i

Don Lewine suggested two ways to flush the cache, the first is to use
the memctl() system call which was designed for this type of thing.  
The second was to chase the data out of the cache. 

Using memctl() is the only way to insure that the code will  be
portable at all.  Since it's a system call, it allows the operating 
system to clean up all caches, pipelines, buffers etc.  
It can be customized for the particular version of the 88000
that your application is running on, and can work correctly 
on any 88000 BCS compliant system.  In fact it may even be fairly
efficient since the 88200 can flush or invalidate a line at a time.

On the other hand there is no way for application software to reliably 
chase data out of a cache.  To define an algorithm that would clear out 
any size cache, any number of caches, any cache associativity, and any 
type of cache is impossible, especially when you consider that you may 
need to clear instruction prefetch buffers, instruction issue pipelines 
and branch caches in addition to clearing the instruction cache(s).   

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