Question

From what I understand reading the Intel manuals, it should be possible to write an instruction like add $0x7f, %ebx and it should be encoded as 83 /0 ib for a total of three bytes.

However, when I do this (whether I use add, addb, or addl) it always “promotes” the immediate value to a 32-bit value and encodes as 81 /0 id and takes up six bytes. The same problem exists with adc, sub, etc. Note that I am using AT&T syntax with GNU as.

I have been looking for a solution for over a day and haven’t found it. Can anyone please advise?

Answer 1

Surprisingly, I don’t have such a problem.

I took this assembly code produced by gcc (DJGPP):

        .file   "im.c"
.globl _x
        .section        .bss
        .p2align 2
_x:
        .space 4
        .section .text
        .p2align 4,,15
.globl _main
_main:
        pushl   %ebp
        movl    %esp, %ebp
        pushl   %eax
        pushl   %eax
        movl    _x, %eax
        andl    $-16, %esp
        addl    $127, %eax
        movl    %eax, _x
        movl    %ebp, %esp
        xorl    %eax, %eax
        popl    %ebp
        ret
        .ident  "GCC: (GNU) 3.3.4"

And compiled it with as and this is what I’m seeing in a.out:

55                push ebp
89E5              mov ebp,esp
50                push eax
50                push eax
A100000000        mov eax,[0x0]
83E4F0            and esp,byte -0x10
83C07F            add eax,byte +0x7f
A300000000        mov [0x0],eax
89EC              mov esp,ebp
31C0              xor eax,eax
5D                pop ebp
C3                ret

And the C program was:

volatile int x = 0;

int main(void)
{
  x += 0x7F;
  return 0;
}

Are you sure your immediate operand can be represented as an 8-bit signed integer? If it’s outside the -128 to +127 range, the assembler will have to use a longer encoding.