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.

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).