Zifencei fence.i

[Jeff Scott]

Hi,

 

I am reading the documentation for this.

 

“A FENCE.I instruction ensures that

a subsequent instruction fetch on a RISC-V hart will see any previous data stores already visible to

the same RISC-V hart.”

 

This statement implies that cache management operations occur as a result of running this instruction.

 

The text does say

 

“The unused fields in the FENCE.I instruction, imm[11:0], rs1, and rd, are reserved for finer-grain

fences in future extensions. For forward compatibility, base implementations shall ignore these

fields, and standard software shall zero these fields.”

 

My question is the following :

 

I would like to have an instruction that causes my instruction prefetch buffer to flush and refetch.  Similar to a branch to next instruction, but the branch instruction does not start until all previous instructions have completed.

 

The use case is when you are modifying instruction triggers, or modifying pmp configurations, and you want the following instructions to represent the results of these modifications, but they have already been prefetched before the modifying instruction has completed.

 

I was thinking FENCE.I was what I was looking for, but then I read the details and it is not what I am looking for.

 

I am sure this scenario has come up for others.  Is there a RISC-V standard way of handling this?   Perhaps using the unused fields of FENCE.I?  Or am I left to create my own custom instruction for this?

 

Once I have this instruction, it would be easy to support self-modifying code with some CMO’s from the standard extension along with this new custom instruction, so I don’t see a need for FENCE.I as defined today.

 

Thanks,

 

Jeff

[Allen Baum]

This depende on whether the definition of "subsequent instruction fetches" assumes that the instruction that follows the execution of FENCE.I  requires a subsequent fetch

(i.e. the fact that it was already in some internal buffer, be it a cache or a prefetch buffer is ignored so it is refetched).

As you say, it does force a cache management op is initiated, and a prefetch buffer is a kind of cache

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/AM6PR04MB605367A104D6550C079412728D699%40AM6PR04MB6053.eurprd04.prod.outlook.com.

[Greg Favor]

On Thu, Dec 2, 2021 at 5:38 PM Allen Baum <allen...@esperantotech.com> wrote:

This depende on whether the definition of "subsequent instruction fetches" assumes that the instruction that follows the execution of FENCE.I  requires a subsequent fetch

(i.e. the fact that it was already in some internal buffer, be it a cache or a prefetch buffer is ignored so it is refetched).

As you say, it does force a cache management op is initiated, and a prefetch buffer is a kind of cache

Architecturally every instruction is "fetched".  After a FENCE.I the immediately following instructions should appear to be "fetched" based on the post- FENCE.I architectural state of the system.  So any caches, prefetch buffers, or decode buffers that are not hardware-coherent should be flushed by the FENCE.I.  With a hardware-coherent instruction cache, only post-cache prefetch/fetch/decode buffers (that are not hardware-coherent) need to be flushed by the FENCE.I.

Greg

 

[Jeff Scott]

Just an update.  I was referred to this:

 

https://github.com/riscv/riscv-j-extension/blob/master/id-consistency-proposal.pdf

 

and IMPORT.I is what I was looking for.  This is very similar to Power ISA isync.

 

Jeff

 

From: Allen Baum <allen...@esperantotech.com>
Sent: Thursday, December 2, 2021 7:38 PM
To: Jeff Scott <jeff....@nxp.com>
Cc: isa...@groups.riscv.org
Subject: [EXT] Re: [isa-dev] Zifencei fence.i

 

Caution: EXT Email