Check if a number is even

后端 未结 2 1525
后悔当初
后悔当初 2021-01-28 18:23

I\'m working my way through low level bit hacks, and would like to write an assembly program for each. Here is what I have for checking if a number is even or not:



        
2条回答
  •  后悔当初
    2021-01-28 18:41

    TL:DR: adding 1 flips the low bit, guaranteed, so you can use lea/and. See below.


    You chose to write a whole function that returns a boolean integer instead of just creating a FLAGS condition (which is all most code needs: test $1, %dil and you're done; branch or cmov or setnz or setz or whatever you actually want to do based one the value being even).

    If you are going to return an integer, then you don't actually need to get the condition into FLAGS and back out, especially if you want a "wide" return value. x86 setcc only writing the low byte is an inconvenient design that requires an extra xor-zeroing instruction most times you want to create a wider 0 / 1 integer. (I wish AMD64 had tidied up the design and changed the meaning of that opcode for 64-bit mode to setcc r/m32 but they didn't.)

    You chose the semantics of your function to return 1 for even; that's opposite of the value of the low bit. (i.e. return (~x)&1;) You also chose to make a function using the x86-64 System V calling convention, imposing overhead from the calling convention taking an arg in a different register than you passed in.

    This function is obviously way too trivial to be worth the call/return overhead; in real life you'd just inline and optimize this into the caller. So optimizing it as a stand-alone function is mostly a silly exercise, except for the idea of getting a 0/1 in a separate register from the original without destroying it.

    If I was writing an answer on https://codegolf.stackexchange.com/, I'd follow this code-golf tip and choose my calling convention to pass an arg in EAX and return a boolean in AL (like gcc -m32 -mregparm=3 would). Or return a FLAGS condition in ZF. Or if allowed, choose my return semantics such that AL=0 meant even, AL=1 meant odd. Then

    # gcc 32-bit regparm calling convention
    is_even:          # input in RAX, bool return value in AL
        not   %eax             # 2 bytes
        and   $1, %al          # 2 bytes
        ret
    
    # custom calling convention:
    is_even:   # input in RDI
               # returns in ZF.  ZF=1 means even
        test  $1, %dil         # 4 bytes.  Would be 2 for AL, 3 for DL or CL (or BL)
        ret
    

    2 instructions without destroying the input

    is_even:
        lea   1(%rdi), %eax          # flip the low bit
        and   $1, %eax               # and isolate
        ret
    

    XOR is add without carry. When the carry-in is zero (guaranteed for the low bit except with ADC), the result for a given bit is the same for XOR and addition. Check the truth table / gate-equivalent for a 1-bit "half adder" (no carry in): the "sum" output is literally just XOR, the carry output is just AND.

    (XOR with 1 flips a bit, same as NOT.)

    In this case, we don't care about the carry-out or any of the high bits (because we're about to nuke those bits with & 1 are the same operation), so we can use LEA as a copy-and-add to flip the low bit.

    Using XOR instead of ADD or SUB is useful for SIMD, where pxor can run on more ports than paddb or psubb on CPUs before Skylake. When you want to range-shift unsigned to signed for pcmpgtb or something, you want to add -128, but that's the same thing as just flipping the high bit of each byte.


    You could use this to flip a higher bit, e.g. lea 8(%rdi), %eax would flip the 1<<3 bit position (and potentially carry into all higher bits). We know the carry-in to that bit will be zero because x + 0 doesn't carry, and the low 3 bits of 8 are all 0.

    (This idea is central to some of the later more interesting bit-hacks in https://catonmat.net/low-level-bit-hacks)

提交回复
热议问题