No announcement yet.

Deciphering Intel Instruction Set

  • Filter
  • Time
  • Show
Clear All
new posts

  • Deciphering Intel Instruction Set

    I am working on a Error Handler, but the more I read the Intel docs as to how instructions are formatted etc. The more confused I get. So I was hoping if I provide 1 example someone can assist me in where my confusion is.

    If I have a "Divide by Zero" Error then the following is what I think is happening.

    1.) I get the location of the Error (Given by the EIP copy of the actual IP when passed to my exception handler)

    2.) If there is a prefix (up to 4 possible) I increment my EIP by 1 byte for each prefix (in this case none found, so I sit at offset 0)

    3.) I then look at the OpCode starting at where my point now is. (in this case offset 0)

    4.) I then determine if a 1 byte or 2 byte op-code (in this case I get "F7 /6")
    Now for this particular example this becomes confusing to me. As the docs say
    /digit—A digit between 0 and 7 indicates that the ModR/M byte of the instruction uses
    only the r/m (register or memory) operand. The reg field contains the digit that provides an
    extension to the instruction's opcode.
    which would be where my "/6" comes into play.

    The rest of the below may be incorrect because I got confused at #4
    5.) At this point my OpCode is F7 and 0 so if a 1 byte opcode (which I think it is) I look at the next byte for the ModR/M

    6.) If the ModR/M exists then I increment to look at the SIB byte (at this point I now have Prefix = 0 bytes, OpCode = 1 byte, ModRM bytes = 1

    7.) If the SIB byte exists then I Increment on to the Immediate and Displacement bytes. But "Wait for it.....Wait for it...." where the heck do I find the immediate and displacement bytes????? they could each be 1,2, or 4 bytes......what did I miss????

    Now I may be amiss with using Divide by zero as an example but I am more for figuring out procedure than I am 1 particular code. If my guess is right then in the case of my example,

    1.) no prefix codes (none that I found anyways)
    2.) 1 byte OpCode
    3.) 1 byte ModR/M
    4.) 1 byte SIB
    Total of 3 bytes to increment and look at the next instruction.....but I could be WAYYYYyyyyy off because of confusion points above.
    Engineer's Motto: If it aint broke take it apart and fix it

    "If at 1st you don't succeed... call it version 1.0"

    "Half of Programming is coding"....."The other 90% is DEBUGGING"

    "Document my code????" .... "WHYYY??? do you think they call it CODE? "

  • #2
    haven't you been here before?

    The first byte of the opcode is F7. In this case that single byte does not specify the entire opcode, it specifies one of a set of opcodes. The extra bits to detrermine which opcode are held in 3 bits of the ModR/M byte that follows.

    The second byte, indicated by /6, means that the ModR/M byte is present, the Mod and the R/M fields of that byte are valid as usual but the reg/opcode field is 6. In the case of /digit in the manual the 3 REG bits of the ModR/M byte do not represent a register, they instead form part of the opcode.

            1st byte    2nd byte/   3rd byte?
            of opcode   ModR/M
    DIV     1111 0111   mm110rrr	
              F    7       /6
    IDIV    1111 0111   mm111rrr
              F    7       /7
    MUL     1111 0111   mm100rrr
              F    7       /4
    mm = the Mod bits and rrr = the R/M bits as usual.
    Whether the third and subsequent bytes exist depends on the values of mm and rrr. You look up what they do in table 2.2 in the Intel manual (Table 2-2. 32-Bit Addressing Forms with the ModR/M Byte)