Re: [PATCH] ppc32 dl-machine.c

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Sat, 28 Sep 2002 01:30:46 +0200
> From: Segher Boessenkool <segher@koffie.nl>

> > > ***except that memory accesses caused by those instructions need not have been performed
> > > with respect to other processors and mechanisms.***
> > >
> > ...
> > 
> > Yes, but we don't care about other processors.  So long as the local
> > icache line is cleared at the point of the isync, and so long as the
> > icache line on other processors gets cleared sometime, everything will
> > work.  It's not like this code is (for instance) loading an object for
> > a thread running on another processor that could try to run the code
> > before a sync is executed.
> 
> It also says (elsewhere) that external cache is one example of such a
> "mechanism", and surprise surprise, on the G4 the L2 needs the sync.

Can you explain why?

It'll make the conversation go noticably faster if you can just
explain all such statements at the time you make them.  Describe the
bus transactions and how they correspond with code execution in a
situation where stale instructions get executed.

> You only need one sync btw, but it has to be _after_ the icbi, not before.
> There's no need for a sync inbetween the dcbst and the icbi.

This is clearly wrong, given the earlier discussion on this list about
prefetching.

> > This code can't flush the icache on other processors if icbi isn't
> > broadcast; it doesn't have access to them.
> 
> As I said, dcbf will probably flush it on other cpu's; but in principal,
> there is _no_ mechanism that will flush other cpu's (or external cache etc).

I see no evidence in the architecture specs for dcbf to have any
effect on the instruction cache.

-- 
- Geoffrey Keating <geoffk@geoffk.org>