CALL opcode

Hi. I'm trying to figure out the encoding for a 32-bit CALL instruction. From the output of FASM I've found that the first byte is consistently E8. The 3rd, 4th and 5th bytes seem to correspond with the most significant bits of the address. My problem is the 2nd byte, which seems inconsistent.

I need this to write a C function which will generate CALL instructions, something like this:

char* gencallop(void* p);

Any help would be appreciated.

Comments

  • It's OK, I've figured it out know. You have to subtract 5 from the address. How queer. This is the code I made to do it:

    [code]char* genopcall(int address, char* buf)
    {
    int i;

    buf[0] = 0xE8;
    address -= 5;

    for(i = 1; i < 5; i++)
    buf[i] = address >> ((i - 1) * 8);

    return buf;
    }[/code]

    I apologise for posting C in the Asm forum, but I thought it was more appropriate since I'm talking about opcodes ;)
  • : It's OK, I've figured it out know. You have to subtract 5 from the address. How queer. This is the code I made to do it:

    [green]
    I've done that kind of testing before and found that if I make the
    simplest (.com) .asm file (Fasm in yer case) with only the instruction
    I'm trying to figgure out, then a
    db 13,10 ; statement
    then the same instruction but with different input
    ;repeat the above here

    then assemble it, but don't run it, just view it with an editor
    the assembled machine code sits one line after another and you can
    see what is the same and what is different quite easily.
    The info gained from try#1 aids in try#2, etc
    and soon your assemblers output gets predictable.

    I don't know if that will help,
    but I gots lots of free time.

    Bitdog
    [/green]

  • : : It's OK, I've figured it out know. You have to subtract 5 from the address. How queer. This is the code I made to do it:
    :
    : [green]
    : I've done that kind of testing before and found that if I make the
    : simplest (.com) .asm file (Fasm in yer case) with only the instruction
    : I'm trying to figgure out, then a
    : db 13,10 ; statement
    : then the same instruction but with different input
    : ;repeat the above here
    :
    : then assemble it, but don't run it, just view it with an editor
    : the assembled machine code sits one line after another and you can
    : see what is the same and what is different quite easily.
    : The info gained from try#1 aids in try#2, etc
    : and soon your assemblers output gets predictable.
    :
    : I don't know if that will help,
    : but I gots lots of free time.
    :
    : Bitdog
    : [/green]
    :
    :
    [blue]I think the best way is to look at the CPU manual, instead of 'guessing' the algorithm of a CALL opcode.[/blue]
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories