Before it was calling `thunks.ProtectFunction()`.  The flow was:

1. Overwrite R8 with a parameter.
2. Call the thunk function.
3. Thunk function calls save_regs -> saves R8 for no reason.
4. Thunk function calls actual function which uses R8.
5. Thunk function restores R8 for no reason.
6. R8 is now the original parameter at least (not garbage.)

New flow here is:

1. Save all regs, including R8 but also other thunk-saved regs.
2. Pass R8 as a parameter.  Do not save it.
2. Call the actual function directly.
3. Restore all regs, including R8.

I actually expected the second version to be faster, though it is not for `ABI_CallFunctionA()`.  I guess I could instead just `PUSH(R8); PUSH(R9);` there, and then POP both afterward (need both to keep aligned), and still call the thunk and pointlessly save/restore regs still.  I actually tested that in the `ABI_CallFunctionA()` case, and it had much larger performance impact than calling save/load around an unthunked version, which is when I decided RCX and RDX were just gonna be left to die if you call something.

Note that `ABI_CallFunctionCCC(func, arg1, arg2, arg3);` is not actually calling the thunk.  This even means it doesn't have to play games on 32 bit.

-[Unknown]