4 ms·

What if you made BINARY_OP a __forceinline (http://msdn.microsoft.com/en-us/library/z8y1yy88.aspx http://msdn.microsoft.com/en-us/library/z8y1yy88.aspx) functio

What if you made BINARY_OP a __forceinline (http://msdn.microsoft.com/en-us/library/z8y1yy88.aspx http://msdn.microsoft.com/en-us/library/z8y1yy88.aspx) function instead of a macro? Things that the function contains that might disable optimization: a lot of gotos, inline assembly in GO_NEXT (this does affect optimization: http://msdn.microsoft.com/en-us/library/5hd5ywk0.aspx http://msdn.microsoft.com/en-us/library/5hd5ywk0.aspx)... It's also not immediately obvious to me that pCurEvalStack is initialized. Having a look at the architecture optimization manual re: the redundant loads; it's not immediately obvious to me that modern processors won't handle this fine (http://www.intel.com/Assets/PDF/manual/248966.pdf http://www.intel.com/Assets/PDF/manual/248966.pdf).

swolchok 15y ago
Looks like I was wrong about the redundant loads. They should probably go away (and indeed you say they do if you put BINARY_OP in its own function).
chrisb 15y ago
Thanks for the idea. Unfortunately it doesn't improve things: pCurEvalStack = TestAdd(pCurEvalStack); 0040BFFA mov eax,dword ptr [pCurEvalStack] 0040BFFD mov dword ptr [ebp-694h],eax 0040C003 mov ecx,dword ptr [ebp-694h] 0040C009 sub ecx,8 0040C00C mov dword ptr [ebp-690h],ecx 0040C012 mov edx,dword ptr [ebp-694h] 0040C018 sub edx,4 0040C01B mov dword ptr [ebp-694h],edx 0040C021 mov eax,dword ptr [ebp-690h] 0040C027 mov ecx,dword ptr [eax] 0040C029 mov edx,dword ptr [ebp-694h] 0040C02F add ecx,dword ptr [edx] 0040C031 mov eax,dword ptr [ebp-690h] 0040C037 mov dword ptr [eax],ecx 0040C039 mov ecx,dword ptr [ebp-694h] 0040C03F mov dword ptr [pCurEvalStack],ecx And also the nice thing about the BINARY_OP() macro is that it can take types and the operator as arguments (e.g. BINARY_OP(I32, I32, I32, +), BINARY_OP(I64, I64, I32, <<) ) meaning it can be used for many operations on many types. I would have to write seperate functions for each case if using in inline function. And pCurEvalStack is initialised in the LOAD_METHOD_STATE macro, referenced first on line 590, before interpretation begins.

swolchok 15y ago

Looks like I was wrong about the redundant loads. They should probably go away (and indeed you say they do if you put BINARY_OP in its own function).

chrisb 15y ago

Thanks for the idea. Unfortunately it doesn't improve things: pCurEvalStack = TestAdd(pCurEvalStack); 0040BFFA mov eax,dword ptr [pCurEvalStack] 0040BFFD mov dword ptr [ebp-694h],eax 0040C003 mov ecx,dword ptr [ebp-694h] 0040C009 sub ecx,8 0040C00C mov dword ptr [ebp-690h],ecx 0040C012 mov edx,dword ptr [ebp-694h] 0040C018 sub edx,4 0040C01B mov dword ptr [ebp-694h],edx 0040C021 mov eax,dword ptr [ebp-690h] 0040C027 mov ecx,dword ptr [eax] 0040C029 mov edx,dword ptr [ebp-694h] 0040C02F add ecx,dword ptr [edx] 0040C031 mov eax,dword ptr [ebp-690h] 0040C037 mov dword ptr [eax],ecx 0040C039 mov ecx,dword ptr [ebp-694h] 0040C03F mov dword ptr [pCurEvalStack],ecx And also the nice thing about the BINARY_OP() macro is that it can take types and the operator as arguments (e.g. BINARY_OP(I32, I32, I32, +), BINARY_OP(I64, I64, I32, <<) ) meaning it can be used for many operations on many types. I would have to write seperate functions for each case if using in inline function. And pCurEvalStack is initialised in the LOAD_METHOD_STATE macro, referenced first on line 590, before interpretation begins.