[Oberon] Emulators / Hardware Enumerator

[Hellwig Geisse]

Michael,

On Sa, 2022-02-12 at 21:31 +0100, Michael Schierl wrote:
> 
> Am 08.02.2022 um 11:58 schrieb Hellwig Geisse:
> > ...
> > "SYSTEM.CCTL(7)" which does the combined D-cache flush and
> > I-cache invalidate needed after loading a module.
> Can you think of any other memory or caching related functionality that
> a generic Oberon distribution would need?
> 

no, not at the moment. Memory read/write barriers come to mind,
but they would only be relevant in multicore implementations.
Atomic test-and-set, or, better, read-locked/write-conditional
instructions fall into the same category.

I'm not a specialist in cache design, sorry. I think it's best
to add any such facilities to the hardware enumerator when they
are really needed. I raised the question merely to point out
that such a device must offer a certain degree of expandability.

> It occurred to me that having to explicitly flush instruction caches
> would also help authors of emulators that do just-in-time instruction
> translation (to decide when to invalidate such translations).

Yes, that's a good point (although my own emulators don't do
JIT translations at the moment).

> To help both use cases, I would add this to the hardware enumerator
> specification:
> 
> 
> -----8<---- cut here -----8<-----
> 
> ### `ICIv`: Instruction cache invalidation
> 
> When present, the CPU has an instruction cache that is not automatically
> invalidated when memory (or data cache) is written to. Therefore, before
> newly written code can be executed, the instruction cache needs to be
> invalidated (and any data cache flushed) by writing a `0` to a MMIO
> address. This can also be used by emulators that do just-in-time
> instruction translation to efficiently flush their translated instructions.
> 
> In case a value other than `0` is written to the MMIO address, the
> hardware may also flush all its instruction cache. Or (if feasible) it
> can only flush those instructions whose memory address is greater or
> equal than the written value.
> 
> Values of the `ICIv` descriptor:
> - MMIO address
> 
> -----8<---- cut here -----8<-----
> 

I think that's a good start. Just a remark: An instruction cache never
needs to be flushed (i.e., written back to memory), invalidation is
sufficient - its contents cannot be altered directly by instructions.
What exactly can be invalidated (a cache line indexed by number or
address, a range of addresses, or the whole cache) is architecture
dependent.

Regards,
Hellwig