martinfnp@yahoo.com writes:
>Does anybody know how can I invalidate content of the cache in user
>space = user process/thread? Thanks.

There are semi-architected instructions called dcb* and icb* that deal
with cache lines. E.g., here's how I ensure that the I-cache does not
constain stale lines:

#include
#include

/* the name is from an AIX (4.3) call (thanks to Dan Prener
for this information) */
void _sync_cache_range(caddr_t addr, size_t size)
{
size_t cache_block_size=32;
caddr_t p=(caddr_t)(((long)addr)&-cache_block_size);

/* this works for a single-processor PPC 604e, but may have
portability problems for other machines; the ultimate solution is
a system call, because the architecture is pretty shoddy in this
area */
for (; p < (addr+size); p+=cache_block_size)
asm("dcbst 0,%0\n sync\n icbi 0,%0"::"r"(p));
asm("sync\n isync"); /* PPC 604e needs the additional sync
according to Tim Olson */
}

The sync between the dcbst and the icbi ensures that the I-cache is
not reloaded from memory before the D-cache has stored its data to
memory. For larger blocks, it is faster to do all the dcbsts, then
one sync, then all the icbis.

Despite the comment about the non-portabilty, this seems to work on
all PPCs I have tried.

- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

If I use malloc or posix_memalign do I have to translate address from
virtual to physical and how before calling function for cache? Thanks.

In article <2006Mar15.184831@mips.complang.tuwien.ac.at>,
Anton Ertl wrote:
>martinfnp@yahoo.com writes:
>>Does anybody know how can I invalidate content of the cache in user
>>space = user process/thread? Thanks.
>
>There are semi-architected instructions called dcb* and icb* that deal
>with cache lines. E.g., here's how I ensure that the I-cache does not
>constain stale lines:
>
>#include
>#include
>
>/* the name is from an AIX (4.3) call (thanks to Dan Prener
> for this information) */
>void _sync_cache_range(caddr_t addr, size_t size)
>{
> size_t cache_block_size=32;
> caddr_t p=(caddr_t)(((long)addr)&-cache_block_size);
>
> /* this works for a single-processor PPC 604e, but may have
> portability problems for other machines; the ultimate solution is
> a system call, because the architecture is pretty shoddy in this
> area */
> for (; p < (addr+size); p+=cache_block_size)
> asm("dcbst 0,%0\n sync\n icbi 0,%0"::"r"(p));
> asm("sync\n isync"); /* PPC 604e needs the additional sync
> according to Tim Olson */
>}
>
>The sync between the dcbst and the icbi ensures that the I-cache is
>not reloaded from memory before the D-cache has stored its data to
>memory. For larger blocks, it is faster to do all the dcbsts, then
>one sync, then all the icbis.
>
>Despite the comment about the non-portabilty, this seems to work on
>all PPCs I have tried.

The version I wrote (for use in the runtime system for the HiPE JIT
compiler for Erlang/OTP) does the dcbsts first, then a sync, then the
icbis, and finally a sync;isync. It's been known to work on 603ev, 750,
G4s, and a POWER4.

I suspect only the weird embedded chips might need something else.
--
Mikael Pettersson (mikpe@csd.uu.se)
Computing Science Department, Uppsala University

martinfnp@yahoo.com writes:
>If I use malloc or posix_memalign do I have to translate address from
>virtual to physical and how before calling function for cache? Thanks.

No, the cache-control instructions work with virtual addresses.

- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html