So I tried to compile NativeJIT with the x86 architecture (using VS2015 on Win7) and stumbled over the following roadblocks:
- Missing BitOperations (
popcnt64, etc) - easily replacable by two calls to their 32bit counterpart
- Missing
RUNTIME_FUNCTION macro (+ some other stuff for stack unwinding) - fixed by using the dummy struct from Unix (I can live with missing stack unwinding on x86, since it doesn't work on Unix systems, I hardly use it anyway)
#error because of missing _AMD64_ flag - just commented out :)
Now these three were easy, but now it gets a little bit more complicated:
- A ton of compilation errors in the
Emit functions because the compiler can't implicitely convert NativeJIT::BaseRegister to NativeJIT::Register<8U, false>. Adding a explicit C-style cast "fixes" those, but I am pretty sure this is not a solution.
- Hitting the static_assert in the
ExpressionTree::Temporary() method: "The size of the variable is too large."
- Some compilation errors when trying to static_cast<> a value to an unsigned int (something like that). This is where I stopped trying :)
This is way too far in the guts of NativeJIT's internals for me to be able to say if trying to support x86 makes any sense at all.
So I tried to compile NativeJIT with the x86 architecture (using VS2015 on Win7) and stumbled over the following roadblocks:
popcnt64, etc) - easily replacable by two calls to their 32bit counterpartRUNTIME_FUNCTIONmacro (+ some other stuff for stack unwinding) - fixed by using the dummystructfrom Unix (I can live with missing stack unwinding on x86, since it doesn't work on Unix systems, I hardly use it anyway)#errorbecause of missing_AMD64_flag - just commented out :)Now these three were easy, but now it gets a little bit more complicated:
Emitfunctions because the compiler can't implicitely convertNativeJIT::BaseRegistertoNativeJIT::Register<8U, false>. Adding a explicit C-style cast "fixes" those, but I am pretty sure this is not a solution.ExpressionTree::Temporary()method: "The size of the variable is too large."This is way too far in the guts of NativeJIT's internals for me to be able to say if trying to support x86 makes any sense at all.