Thanks a lot, it is quite clear now On Thu, 19 Jun 2003, Barry Bond wrote:
> 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", the 7 from the > CMP opcode, and "rm=3", where the mod/rm bits mean "register ebx". The > Emit8(0) that follows copies the value of the imm8 field in the opcode. > > The code could have also been written as: > Emit8(0x83); > Emit8(0xfb); > Emit8(0x00); > But the C compiler won't produce as efficient code as it will for > Emit16(0xfb83). > > Barry > This posting is provided "AS IS" with no warranties, and confers no > rights. > > -----Original Message----- > From: Discussion of the Rotor Shared Source CLI implementation > [mailto:[EMAIL PROTECTED] On Behalf Of Archana > Sent: Thursday, June 19, 2003 3:24 AM > To: [EMAIL PROTECTED] > Subject: [DOTNET-ROTOR] Assembly codes in jitinterfacex86.cpp > > 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 > // cmp edx,0 > > what parameter should be passed to Emit16 etc.. > > Thanks, > archana >
