Emit32/16/8 just copies the 32/16/8-bit argument directly into the
output buffer with no mapping.
In your example, 0xfb83 is little-endian for bytes 0x83 0xfb, where 0x83
is the x86 opcode "CMP r/m32, imm8" (which Intel documents as opcode "83
/7 ib", and 0xfb is the mod/rm byte, encoding "mod=3",
Remember that nearly all code in the SSCLI tree sits on top of the PAL
DLL, not on top of the host OS and C Runtimes. Except for the PAL,
nothing in Rotor uses #include to pull in OS or C Runtime header files -
instead, everything #includes rotor_pal.h. You're probably seeing
collisions between t
Hi,
Is there any documentation regarding the opcodes used in the file
jitinterfacex86.cpp and how the intel opcodes are mapped onto these codes
for example this is a piece of code from vm/i386/cgencpu.cpp,
// cmp ebx,0
Emit16(0xfb83);
Emit8(0);
if one needs to write
// cm
