Hi Andreas, hi midnite,
I've dug a little deeper (and brushed off my assembly skills) and I've seem to have found what happens.
The optimizer assumes it has the whole FPU-stack (ST(0..7)) available to place the arguments on. That way it can efficiently store them in
fvalues[] and use them to compare them to the expected values. However, on entry of the function, the FPU-stack already contains 2 elements (TAGS=0x0FFF). So, when f15 and f16 are pushed on the stack, the stack is full, leading to the failed test.
I've currently 'fixed'
TestExecuteThis32MixedArgs by modifying
CallThisCallFunction by adding fsave/frstor instructions (see below).
I'm however not really sure about the ramifications. The overhead for fsave/frstor is now payed for every function call, but I'm unsure how much that is exactly. I have no idea what the existing values on the stack represent, and if they need to be restored at all. Maybe a
fninit-instruction can be used without harm?
This would be something a more asm-savvy person should look into, I guess.
Anyway, I hope this helps. Enjoy your holiday!
void CallThisCallFunction(const void *obj, const asDWORD *args, int paramSize, size_t func){---> char fpuState[108]; __asm { // We must save registers that are used push ecx---> fsave fpuState // Copy arguments from script // stack to application stack mov ecx, paramSize mov eax, args add eax, ecx cmp ecx, 0 je endcopycopyloop: sub eax, 4 push dword ptr [eax] sub ecx, 4 jne copyloopendcopy: // Move object pointer to ECX mov ecx, obj // Call function call [func] // Restore registers pop ecx---> frstor fpuState // Return value in EAX or EAX:EDX }}
