-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider using dispatch tables for memory reading and writing #3
Comments
Looks like a good idea. I'll give it a try further down the line. |
Also the games can execute instructions from the their RAM, and often do for waiting out OAM DMA, so make sure you can successfully cover invalidation of the code cache. |
That's a definite chunk of complexity right there. Odds are that I'll just avoid caching any executable instructions in RAM. The real focus of this project is fiddling around with LLVM to produce a mostly native binary of the ROM. It might be worth using the JIT to handle "live" code, though :) |
Yeah, still might be worth it to JIT the busy-wait loops that are often found in RAM in many games. |
It'll be interesting to do some profiling on the effects of JIT with cache invalidation compared to interpreted execution. |
The cases of busy-wait are busy enough to hard-code optimizations upon. |
Essentially you can make a table that holds pointers to handling sub-routines for addresses being requested. The GameBoy/GameBoy Color memory map is only 16-bit (albeit with ROM and RAM banking), so it can easily be mapped. This is faster than if/else'ing like a mad-man for address decoding.
The text was updated successfully, but these errors were encountered: