lkml.org 
[lkml]   [2007]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 4/7] Immediate Values - i386 Optimization
    * H. Peter Anvin (hpa@zytor.com) wrote:
    > Mathieu Desnoyers wrote:
    > >
    > >I have tried generating asm-to-"register" c variables for char, short
    > >and int on i386 and I do not see this happening. The char opcode is
    > >always 1 byte, short 2 bytes and int 1 byte. Result:
    > >
    >
    > The comment was referring to x86-64, but I incorrectly remembered that
    > applying to "movq $imm,%reg" as opposed to loading from an absolute
    > address. gas actually has a special opcode (movabs) for the 64-bit
    > version of the latter variant, which is only available with %rax and its
    > subregisters.
    >
    > Nevermind, in other words. It's still true, though, that the immediate
    > will always be the last thing in the instruction -- that's a fixture of
    > the instruction format.
    >

    Hrm, some basic testing shows me that, on x86_64:

    register long var, var2, var3, var4, var5;
    asm ("movq $0xFFFFFFFF,%0;\n\t" : "=r" (var) :);
    asm ("movq $0x100000000,%0;\n\t" : "=r" (var2) :);
    asm ("movq $0,%0;\n\t" : "=r" (var3) :);
    asm ("movq $0xFFFFFFFFFFFFFFFF,%0;\n\t" : "=r" (var4) :);
    asm ("movq $0xFEFEFEFE01010101,%0;\n\t" : "=r" (var5) :);

    generates:

    ae: 48 be ff ff ff ff 00 mov $0xffffffff,%rsi
    b5: 00 00 00
    b8: 48 bf 00 00 00 00 01 mov $0x100000000,%rdi
    bf: 00 00 00
    c2: 48 c7 c1 00 00 00 00 mov $0x0,%rcx
    c9: 48 c7 c2 ff ff ff ff mov $0xffffffffffffffff,%rdx
    d0: 48 b8 01 01 01 01 fe mov $0xfefefefe01010101,%rax
    d7: fe fe fe

    So we have to deal with the fact that gas produces opcodes of
    different size (2 and 3 bytes) and with different immediate value sizes
    for 8 bytes load immediates, depending on the immediate value to load.
    There even seems to be an implicit duplication of the value when the
    lower and higher 32 bits of the immediate value are the same (the
    0xFFFFFFFFFFFFFFFF case).

    Therefore, I propose the following. We should use the

    asm ("movq $0xFEFEFEFE01010101,%0;\n\t" : "=r" (var5) :);

    to make sure we always deal with the same instruction and have a 8 bytes
    immediate value. We don't really care about the static value given
    because we always update it dynamically before the first time it is
    executed.

    > >gcc version 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)
    > >
    > > 8: b3 02 mov $0x2,%bl
    > > a: b1 03 mov $0x3,%cl
    > > c: b2 04 mov $0x4,%dl
    > > e: b0 05 mov $0x5,%al
    > >
    > > 4f: 66 be 06 00 mov $0x6,%si
    > > 53: 66 bb 07 00 mov $0x7,%bx
    > > 57: 66 b9 08 00 mov $0x8,%cx
    > > 5b: 66 ba 09 00 mov $0x9,%dx
    > > 5f: 66 b8 0a 00 mov $0xa,%ax
    > >
    > > 9f: bb 0b 00 00 00 mov $0xb,%ebx
    > > a4: be 0c 00 00 00 mov $0xc,%esi
    > > a9: b9 0d 00 00 00 mov $0xd,%ecx
    > > ae: ba 0e 00 00 00 mov $0xe,%edx
    > > b3: b8 0f 00 00 00 mov $0xf,%eax
    > >
    > >
    > >I notice that having a "=r" inline assembly that outputs to the first
    > >"register char" variable seems to be problematic. It fails with the
    > >following error:
    > >
    > >/tmp/ccy35Hq1.s: Assembler messages:
    > >/tmp/ccy35Hq1.s:15: Error: bad register name `%sil'
    >
    > 'r' is wrong for 8-bit variables on i386. It needs to be 'q'.
    >

    Will fix. I noticed that it was because I had too much "register" char
    variables declared and used at the same time. Putting a "g" constraint
    gave the same result.

    Mathieu

    --
    Mathieu Desnoyers
    Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
    OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-10-22 17:47    [W:0.025 / U:4.972 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site