@GDCPresoReviews@mastodon.gamedev.place
2026-04-27 03:08 UTC
At the end of the handler, you set the Trap Flag again, so the next instruction gets another trap. So your handler ends up getting called every time an instruction gets executed.
In the handler, you can parse the instruction, and look at the register state to determine which memory accesses that instruction is performing.
Now that you're seeing all the memory operations, you can model the behavior of a cache, to see whether you expect that operation to hit or miss.
2/4
Replies (1)
-
@GDCPresoReviews@mastodon.gamedev.place 2026-04-27 03:17
This is neat because you can model any cache behavior - not just the cache of the machine you're running on - so they modeled the Jaguar's cache. And they captured the instruction pointer and the stack to attribute the accesses back to source code. In the end, they ended up with a UI like this, which colored lines of code according to how many cache misses they caused. They also had a tree view, too. 3/4