Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpda!hpcupt1!vitale
From: vitale@hpcupt1.cup.hp.com (Phil Vitale)
Newsgroups: comp.arch
Subject: Re: overview of HP-PA Bitfield insts.
Message-ID: <68440001@hpcupt1.cup.hp.com>
Date: 19 Apr 91 01:11:22 GMT
References: <51584@apple.Apple.COM>
Organization: Hewlett Packard, Cupertino
Lines: 30

> (Lawrence D'Oliveiro, Waikato University)
> Hmmm, I seem to recall from another discussion some time ago that the
> HP-PA is one of those processors that will correctly invalidate its 
> instruction cache if you do any writes to program code in memory.

You need to execute a Flush Instruction Cache (FIC) to make sure the old
line is out of the instruction cache.

On HP-UX, page protection prevents mortal users from writing to program code
in memory.  However, mortal users can execute from data in memory.  This
means you have to think about the data cache that may be on your machine.

To handle the data cache, the Flush Data Cache (FDC) instruction should
be used to make sure memory has the latest copy of the modified code.

You only need to use the flush pair once per cache line.  Cache line size
is implementation dependent.

Now, having said that, the flushes may not be necessary under certain
conditions:  (1) You are able to write to program code in memory (special 
page permissions), and (2) the HP-PA implementation you were using has a
unified I and D cache (850 for example).  It's a lot more portable across
HP-PA implementations to use the flushes.

On a related note, the ASPLOS-IV proceedings had a paper on a portable
implementation for self-modifying code.


Phil Vitale
vitale@hpda.cup.hp.com