[Taniwha]

It's worth noting that on systems with real cache coherency (MOESI for example) where for example writing data into the dcache to an address A results in cache line shootdown in the icache as part of fetching an 'exclusive/modified' line into the dcache - in this world EXPORT.I is essentially a no-op because what it requires the icache implement (shootdown of icache lines) has already happened naturally.

Equally on such a system the only thing left for FENCE.I to do is to flush any (potentially now bogus) subsequent instructions that are in the execution pipe that might have been prefetched before the writes occurred. In such a system FENCE.I and IMPORT.I are identical.

Hopefully the people writing this spec are listening ... please make sure your spec understands high end systems like this and doesn't add stuff that require special cases in systems that do ubiquitous coherency right

[sdbbp]

This organization of functionality is intentional. It provides support for code modification orthogonal to instruction cache coherency support. The range of types of implementations of RISC-V is broad enough that imposing instruction cache coherency on all of them wouldn't be optimal. The I/D consistency proposal provides SW control now, while not requiring particular implementations.

Particular RISC-V Platform specs may end up requiring I/D coherency, like Arm is recommending in SBSA Level 6, but that's left for later, if ever.

[Taniwha]

Right, I think it's OK as written, I'm just encouraging people to make general specs rather than ones with special cases that are important for one end but slow everything else down