Apparently I didn't explain the idea sufficiently enough. I'll try it with examples (with x86 instructions, because I'm not familiar with 68k). Currently you are calling functions like this: push par4 push par3 push par2 push par1 call function add esp, 4*4 Right. You can achieve the same with this …

The illegal reads are not while executing dynrec code! The dynrec function calling and code execution looks good now.

@M-HT I believe the stack on both the 68k and x86 grows negative. The x86: push par1 is actually: move par1,-(sp) And pop is: move (sp)+,par1 Where sp is the stack pointer and we use () instead of the x86 [] to represent memory indirect (we do use () and [] in double memory indirect addressing modes …

I think I've figured out how to make _fastcall, _stdcall, and _cdecl compatible using the same interface. I've defined an optional new variable called DRC_STACKPARM for risc_anyCPU.h that pushes the _cdecl and _stdcall missing paramaters to the stack in decoder_basic.h gen_call_function_R3(), gen_ …

Have you taken a look at the other platforms ? Do arm and mipsel handle it differently ? RISC ABI's (and risc_x64.h) pretty much all specify register based function parameters and this default is built into GCC for those platforms. The GCC _fastcall function attribute is ignored (doesn't exist) on …

Do you really think anyone wants to answer now, after being called names? Nobody called anybody names. I asked if you were going to be a#?*#s and you responded. It's not like anybody would have replied by now anyway. @NovaCoder You were right. Waste of time. So much for doing the responsible thing …

🙁

I have been working with NovaCoder to enable 68k dynrec support. I have the dynrec cache buffers executing code but I believe I have found several bugs. Making function parameters fully stack based causes problems. This can be experienced by turning off the GCC fastcall function attribute (#define …