Do externally-requested interrupts invalidate a cached I_STAT?

[ghost]

Hi! It's me again. :)

Here it is written:

The functionality of the Cache is still widely unknown. Not sure if DMA transfers are updating or invalidating cache.

I think that IRQs caused by DMA transfers must invalidate the corresponding cache entry, and that this also must apply more generally to all IRQs issued outside the CPU (e.g., V-blank, timers, GPU). My reasoning stems from the following snippet of code found in the PSX BIOS (10j):

In wait_for_vblank, the BIOS repeatedly polls I_STAT, expecting the IRQ flag for V-blanks to change. However, it is using the cached address for I_STAT, 0x1f801070. Note that the I-cache is enabled at this point. Because this spins infinitely if there is a cached entry for I_STAT with the corresponding bit set to 0—which there is, at least in my testing—this cannot be correct behavior unless V-blanks invalidate cache. I don't yet have the evidence to generalize this for all externally-requested interrupts, but it would make a lot of sense.

[nicolasnoble]

The cache is only for code, not data. You can never hit the cache when loading or writing data, only when executing code.

[ghost]

Ah, that makes a lot of sense. Do you mind if I ask how the CPU determines if something is code or data? Is it that all instruction fetches from cached regions consult the I-cache, and data fetches don't?

[nicolasnoble]

Basically what you're saying, yes: the i-cache will be used for instruction fetches when executing code. There is no d-cache, only the scratchpad. So any load or store will be performed on the corresponding memory region directly. The only detail is there's a 4-words deep write queue. See https://psx-spx.consoledev.net/memorymap/#write-queue

[ghost]

Thanks! Interestingly, I implemented this properly in my emulator previously, but for whatever reason, I scrapped it. Thank god for Git.