Author Topic: Odd hex code? or not?  (Read 8844 times)

Offline brandonhill7

  • Jr. Member
  • *
  • Posts: 2
Odd hex code? or not?
« on: January 21, 2011, 04:32:23 AM »
I am trying to read through the intel IA-32 manuals and have found the hex codes for the instructions. I am not sure why but nasm produces "83 C0 FF" when I compile the following simple program.

BITS 32;

start:
        ADD EAX, 0FFFFFFFFh

Is this a problem? Does FF encode FFFFFFFFh? Why the does it seem to assemble the way it should when I use EFFFFFFFh instead, producing "83 C0 EF FF FF FF".

I am most probably missing something but the opcode and MODr/m bytes seem all right while the opcode doesnt seem right.
Could someone tell me what it is that produces this?

Thanks,
Brandon

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: Odd hex code? or not?
« Reply #1 on: January 21, 2011, 02:01:59 PM »
"ADD" is one of several instructions that have a "signed byte" form. If the operand will fit in a signed byte, it is stored as a byte and sign-extended to a word/dword/qword(?). Compare opcodes 81 and 83.

Best,
Frank


Offline brandonhill7

  • Jr. Member
  • *
  • Posts: 2
Re: Odd hex code? or not?
« Reply #2 on: January 21, 2011, 10:43:47 PM »
I think I understand that 83h takes a single byte and 81 takes 4. Is 83h then only for shortening a program?

How does the "signed byte" form work? Does opcode 83h assume that you will provide one byte to be extended? Will any form of 4 repeating bytes be compressed to one?
(Ex: AE AE AE AE --> AEh)

It doesn't seem that way as "ADD EAX 0EFEFEFEFh" assembles to "81 C0 EF EF EF EF"...

Thanks to Frank for his answer.
Brandon.
« Last Edit: January 25, 2011, 01:39:22 PM by brandonhill7 »