05-15-2014, 03:33 AM
Well, the decode step is more basic than what you're thinking. Specifically, it involves:
1. Memory fetch (what instruction is it?)
2. Byteswap (PPC instructions are in big endian.)
3. Table lookup(s) - determine encoding of instruction and packed parameters.
4. Dispatch (call the function which can handle the instruction.)
The only step above that can practically be removed on a complicated architecture is step 2. A shadow copy of the binary could be kept pre-byteswapped, and all instructions read from there. This could be a win, depending on how much time the CPU actually spends on byteswapping. I think BSWAP is quite fast.
Anyway, the table lookup is hard to avoid. You either need to pack things in different lanes and generally deal with decoding and tables, or you need to make the instructions bigger. If they're bigger, then you spend more time on step 1. It could be tested, but I would not expect it to be a win.
You can't avoid dispatch or memory fetch without actually recompiling it. Any kind of recompiler will avoid all four of those steps, and inline the actual operation - including jit.
Using AOT instead of JIT may be relevant for the PS3. Someone mentioned to me that games were forbidden from modifying executable code, which is great news. There are some cases where AOT can be tricky, though, specifically switch jump tables in some cases... but I'm not very familiar with PowerPC or how code is generated for it by compilers usually, so that may not be an issue or it may be a larger issue than I expect.
Certainly no game binary is 10GB. The size of the disc is irrelevant for AOT, only the binary matters. It will never be larger than 256MB, since the PS3 only has 256MB of RAM. However, there's likely some means of dynamically loading binaries (like dlls), and "finding" these for AOT compilation may either be very easy or tricky.
For example, the PSP does allow self modifying code, which some PSP games use, and games can even load binary code from a datafile into memory and call it. They can also call official functions to load dynamic modules, either from data files or even from memory (which may ultimately be from a compressed or packed data file.)
So, AOT makes sense if the PS3 does not have those problems, or has them in well-defined, easily detectable ways (and if homebrew doesn't need them either.)
Anyway, rpcs3 currently spends lots of time (and memory accesses) on each of the 4 steps above. Except step 2, each one involves at least one, and probably multiple, virtual method lookups (which will be cached at least, probably, but are individual memory accesses.)
-[Unknown]
1. Memory fetch (what instruction is it?)
2. Byteswap (PPC instructions are in big endian.)
3. Table lookup(s) - determine encoding of instruction and packed parameters.
4. Dispatch (call the function which can handle the instruction.)
The only step above that can practically be removed on a complicated architecture is step 2. A shadow copy of the binary could be kept pre-byteswapped, and all instructions read from there. This could be a win, depending on how much time the CPU actually spends on byteswapping. I think BSWAP is quite fast.
Anyway, the table lookup is hard to avoid. You either need to pack things in different lanes and generally deal with decoding and tables, or you need to make the instructions bigger. If they're bigger, then you spend more time on step 1. It could be tested, but I would not expect it to be a win.
You can't avoid dispatch or memory fetch without actually recompiling it. Any kind of recompiler will avoid all four of those steps, and inline the actual operation - including jit.
Using AOT instead of JIT may be relevant for the PS3. Someone mentioned to me that games were forbidden from modifying executable code, which is great news. There are some cases where AOT can be tricky, though, specifically switch jump tables in some cases... but I'm not very familiar with PowerPC or how code is generated for it by compilers usually, so that may not be an issue or it may be a larger issue than I expect.
Certainly no game binary is 10GB. The size of the disc is irrelevant for AOT, only the binary matters. It will never be larger than 256MB, since the PS3 only has 256MB of RAM. However, there's likely some means of dynamically loading binaries (like dlls), and "finding" these for AOT compilation may either be very easy or tricky.
For example, the PSP does allow self modifying code, which some PSP games use, and games can even load binary code from a datafile into memory and call it. They can also call official functions to load dynamic modules, either from data files or even from memory (which may ultimately be from a compressed or packed data file.)
So, AOT makes sense if the PS3 does not have those problems, or has them in well-defined, easily detectable ways (and if homebrew doesn't need them either.)
Anyway, rpcs3 currently spends lots of time (and memory accesses) on each of the 4 steps above. Except step 2, each one involves at least one, and probably multiple, virtual method lookups (which will be cached at least, probably, but are individual memory accesses.)
-[Unknown]