Rewrite cache management functions

[Ziemas]

First of all, I totally understand if people think it's best to leave this well enough alone.

The previous implementation looped over and read both ways of every cache line, doing a manual comparison of the address and then doing index invalidate on match.

This replaces that with a simple loop over each cache line using the Hit invalidate cache ops, which will tell the hardware to check for a cache hit and invalidate.

Doing things this way should mean it's safe to do without disabling interrupts, which is how sceSifWriteBackDCache worked. Because of that I've made it use the same shared implementation, this does miss some loop unrolling from that function because I don't imagine it matters much?

[rickgaiser]

Nice improvement in code readability!
As for the functional change, I think you're right, but I've also been experimenting with this stuff a while back and it's very tricky to get right, and easy to get wrong.

I see you've made a few changes after making the PR. Take your time and let me know when it's ready to merge.

[Ziemas]

It kept bugging me how easy it is to accidentally affect one more line than you intended with SyncDCache/InvalidDCache, since the range end is inclusive SyncDCache(0, 64) is syncing two cache lines and I see most code using it just add a size without subtracting 1. That's not so bad for writeback, but could be bad for invalidate.

So I added a cache.h with inline cache management functions that make sense to me.

[uyjulian]

Looks good

[sp193]

The existing cache functionality is designed and documented by Sony and so the limitation of writing back in units of 64 is known. If you have nice macros for improving its behaviour, I suppose that would be a nice addition.

Personally, I used to make use the uncached or even uncached+accelerated memory region where its characteristics fit better better than writing back/invalidating the data cache lines, since there is no need to write in blocks of 64. However, we are cautioned against mixing access modes within a cache line.

I am retired, but I hope to share my 2-cents. But feel free to carry on if we can manage this.
I feel that it is possible that undocumented/poorly-understood hardware issues/behaviour to occur if we deviate from the original design. For this reason, I used to work towards eliminating code that worked differently from the Sony original.

[Ziemas]

The existing cache functionality is designed and documented by Sony and so the limitation of writing back in units of 64 is known. If you have nice macros for improving its behaviour, I suppose that would be a nice addition.

My main problem is that I see it misused all over PS2SDK when it does something like SyncDCache(ptr, ptr+size) where if the size is a multiple of the line size it'll write back an unrelated line at the end.

Personally, I used to make use the uncached or even uncached+accelerated memory region where its characteristics fit better better than writing back/invalidating the data cache lines, since there is no need to write in blocks of 64. However, we are cautioned against mixing access modes within a cache line.

I agree, using UCAB memory for writing DMA lists is great.

I am retired, but I hope to share my 2-cents. But feel free to carry on if we can manage this. I feel that it is possible that undocumented/poorly-understood hardware issues/behaviour to occur if we deviate from the original design. For this reason, I used to work towards eliminating code that worked differently from the Sony original.

In this case sceSifWriteBackDCache() was already using the hit writeback invalidate function that i use here.