Implement direct mapped cache for instruction fetch

[yy214123]

Extend the existing architecture to cache the last fetched PC instruction, improving instruction fetch hit rate by approximately 2%.

based on performance metrics introduced in #99 (MMU Cache Statistics).

=== MMU Cache Statistics ===

Hart 0:
   Fetch: 443724828 hits,    7671580 misses (98.30% hit rate)
   Load:   65003296 hits,   34592372 misses (2-way) (65.27% hit rate)
   Store:  59967516 hits,   11483892 misses (83.93% hit rate)

Also includes clang-format fixes for several expressions.

---

Summary by cubic

Implemented a direct-mapped instruction fetch cache with a small victim cache to reduce conflict misses and speed up fetches. Improves instruction fetch hit rate by ~2% (per MMU cache stats from #99) and reduces fetch translations by ~10%.

• New Features

  • Direct-mapped I-cache (256 blocks × 256 B).
  • 16-block victim cache with swap-on-hit to mitigate conflict misses.
  • I-cache invalidation on MMU invalidate.
  • 2-entry direct-mapped fetch page cache with parity hash to avoid thrashing.

• Refactors

  • Documented I-cache macros/masks and renamed IC/VC prefixes to ICACHE/VCACHE.
  • Fixed tag calculation, victim-cache fill, and hit/miss accounting in mmu_fetch.

^{Written for commit 1ff3c37. Summary will update automatically on new commits.}

[jserv]

Consider 2-Way Page Cache: Given that the current page-level cache already achieves 98.30% hit rate, consider simply upgrading it instead:

  // Current: single-entry page cache
  mmu_fetch_cache_t cache_fetch;

  // Proposed: 2-way set-associative page cache
  mmu_fetch_cache_t cache_fetch[2];  // Only +16 bytes overhead

  Use parity hash (like load/store caches):
  uint32_t idx = __builtin_parity(vpn) & 0x1;
  if (unlikely(vpn != vm->cache_fetch[idx].n_pages)) {
      // ... fill
  }

[jserv]

Unify the naming scheme.

[jserv]

Rebase the latest 'master' branch and resolve build errors.

[jserv]

Squash commits and refine commit message.

[visitorckw]

This series appears to contain several "fix-up," "refactor," or "build-fix" commits that correct or adjust a preceding patch.

To maintain a clean history and ensure the project is bisectable, each patch in a series should be complete and correct on its own.

[visitorckw]

As a friendly reminder regarding project communication:

Please ensure that when you quote-reply to others' comments, you do not translate the quoted text into any language other than English.

This is an open-source project, and it's important that we keep all discussions in English. This ensures that the conversation remains accessible to everyone in the community, including current and future participants who may not be familiar with other languages.

[visitorckw]

This code looks suspicious to me.

When you move the evicted I-cache block (tmp) back into the victim cache, you are setting the vblk->tag to tmp.tag, which is the 16-bit I-cache tag.

Won't this corrupts the victim cache entry? The VC search logic requires a 24-bit tag ([ICache Tag | ICache Index]) to function. Because you're only storing the 16-bit tag, this VCache entry will never be hit again.

[yy214123]

Won't this corrupts the victim cache entry? The VC search logic requires a 24-bit tag ([ICache Tag | ICache Index]) to function. Because you're only storing the 16-bit tag, this VCache entry will never be hit again.

Thank you for pointing that out. I’ve added the following expressions to ensure correctness :

+   vblk->tag = (tmp.tag << ICACHE_INDEX_BITS) | idx;

[yy214123]

...

To maintain a clean history and ensure the project is bisectable, each patch in a series should be complete and correct on its own.

I've finished cleaning up the commits and split them into three functionally independent patches.

Please ensure that when you quote-reply to others' comments, you do not translate the quoted text into any language other than English.

Thank you for pointing that out. I've corrected the mistake and will be more careful in the future.

[jserv]

It is not worthy to invoke __builtin_ctz for constants.

[yy214123]

The reason it was designed this way is because I initially needed to experiment with various cache size combinations.
Do you mean it's better to just directly fill in the log2 value?

-   #define ICACHE_OFFSET_BITS (__builtin_ctz((ICACHE_BLOCKS_SIZE)))
-   #define ICACHE_INDEX_BITS (__builtin_ctz((ICACHE_BLOCKS)))
+   #define ICACHE_OFFSET_BITS  8
+   #define ICACHE_INDEX_BITS 8

[visitorckw]

Shouldn't clz be used here instead of ctz?

Additionally, I don't think the logic for calculating ilog2 and its relationship with clz belongs in riscv.h. IMHO, this isn't RISC-V specific and should be placed in a more general helper file.

Furthermore, if we were to introduce such a helper, we shouldn't rely solely on the gnu extensions __builtin_clz()/ctz(). We would also need to provide a fallback implementation for compilers that don't support them to avoid compatibility issues.

However, since this is just a pre-computable value in this context, I don't believe it's necessary to introduce such a helper at all.

[yy214123]

Shouldn't clz be used here instead of ctz?

I only considered the case where the value is a power of two. For non–power-of-two values, clz should indeed be used.

We would also need to provide a fallback implementation for compilers that don't support them to avoid compatibility issues.

Thanks for pointing that out. After reviewing the code, I noticed that __builtin_parity already accounts for this situation.
I’ll be more careful when using similar compiler extensions in the future.

#if !defined(__GNUC__) && !defined(__clang__)
/* Portable parity implementation for non-GCC/Clang compilers */
static inline unsigned int __builtin_parity(unsigned int x)
{
    x ^= x >> 16;
    x ^= x >> 8;
    x ^= x >> 4;
    x ^= x >> 2;
    x ^= x >> 1;
    return x & 1;
}
#endif

Additionally, I don't think the logic for calculating ilog2 and its relationship with clz belongs in riscv.h. IMHO, this isn't RISC-V specific and should be placed in a more general helper file.

I’ve already defined it as a constant.

On a related note, I’d like to ask for your advice — I currently place the structures for the i-cache and victim cache, along with their related #defines, inside riscv.h.

Would you suggest separating these parts into a new header file instead?

[visitorckw]

Rather than discussing which header they should go into, I’m more interested in knowing how likely it is that these will be shared with other C files in the future. If the probability is low, should they just be placed directly in riscv.c instead of a header?