[libre-riscv-dev] Power memory fences and icache handling

[Luke Kenneth Casson Leighton]

On Tuesday, May 12, 2020, Jacob Lifshay <programmerjake at gmail.com> wrote:

> On Mon, May 11, 2020, 17:54 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
> > On Tuesday, May 12, 2020, Yehowshua <yimmanuel3 at gatech.edu> wrote:
> >
> > > > dcache:
> > > > https://github.com/paulusmack/microwatt/blob/mmu/dcache.vhdl <
> > > https://github.com/paulusmack/microwatt/blob/mmu/dcache.vhdl>
> > > >
> > > > icache:
> > > > https://github.com/paulusmack/microwatt/blob/mmu/icache.vhdl <
> > > https://github.com/paulusmack/microwatt/blob/mmu/icache.vhdl>
> > >
> > >
> > > I was actually talking to Michael about that the other day.
> > >
> > > If you have an instruction that does a store to a location in the
> icache,
> >
> >
> > that is prohibited by design.
> >
>
> If you're trying to run a standard Linux OS, writing to memory that could
> be in the icache is required, that's how the dynamic linker works.


my understabding of this is that writing to memory as a data page, then
flushing it and reloading it into the icache, is a workaround.


> Additionally, loading code from disk (e.g. the exec() call) or JIT
> compilation also requires writing to memory then executing it. In all of
> those cases one or more icache invalidate and then an isync instruction (or
> other context synchronizing instruction) are run before running the
> modified code.


that would... ok if the icache is entirely invalidated following a write
through the dcache, it would load  the modified executable


>
> Note: it turns out that isync doesn't do any icache flushing without
> additional icache invalidate instructions, so it's not quite as expensive
> as I had originally thought for Power atomics, however, it still restarts
> fetching and decoding instructions, so is still more expensive than
> necessary for just using it as an atomic fence.


hmmm




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68