Checking the sign of one or more numbers

Question

Related to Doing something in assembly vs having the assembler do it, I've tried my hand at checking the sign of a single number or multiple packed numbers, using the assembler to do much of the heavy lifting:

# Checking sign / unpacking values
# to check the sign, of an N-bit number, we can do check the left-most bit:
#   1 << (num_bits - 1)
# For example: for a signed 16 bit number, we can do:
#   NUM & (1 << 15) --> if this is NOT ZERO, it means the left-most bit was set and thus is a negative (signed) number

# (1) checking a single number
NEG_NUM = -4
mov $NEG_NUM, %ax
test $(1 << (16-1)),  %ax
setnz %r11b

POS_NUM = 4
mov $POS_NUM, %ax
test $(1 << (16-1)),  %ax
setnz %r12b

# (2) checking multiple numbers packed into a single value
# pack two 16-bit values into %eax -- signed short nums[] = {10, -2}
NEG_MULTI_PART_NUM = 0x000AAFFE
mov $NEG_MULTI_PART_NUM, %eax
test $(1 << (32-1) | (1 << (16-1))), %eax
setnz %r13b

POS_MULTI_PART_NUM = 0x0B003F1E
mov $POS_MULTI_PART_NUM, %eax
test $(1 << (32-1) | (1 << (16-1))), %eax
setnz %r14b

I have a few questions related to this:

• Is test $(1 << (numbits-1))...setnz the most common way to check if a signed number is negative? If not, what's a better way to do so?
• To check the MSB in two packaged 2-byte values I'm doing test $(1 << (32-1) | (1 << (16-1))). Again, does this seem like a good way to do this? Is the above considered unreadable, or is that clear enough?

Answer 1

x86 has a Sign Flag, SF. test same, same / sets %al would be idiomatic. No need to waste code size on an immediate for test when the bit you want already has a special FLAGS result just for it.

Look at compiler output for int foo(int x) {return x<0;}. How to remove "noise" from GCC/clang assembly output?. Get in the habit of seeing how a compiler does something (with optimization enabled) any time you're wondering, before you take the time to ask other humans about it. (Sometimes you'll realize "oh that makes sense" and not have to ask, or at least it will inform your question.)

Actually, clever compilers will just use a logical right-shift to isolate the sign bit at the bottom of the register, never going through FLAGS at all.

---

For checking if either of multiple numbers are negative, yes a sign-bit mask works. Normally you'd write it as a hex constant like 0x80008000. The position of the set bits in that is pretty easy to take in with hex, and asm should normally be well commented anyway so any mention of signs in a comment is enough of a clue about exactly what that bitmask is doing for anyone for whom it wasn't immediate obvious.

If you do want to write it as 1<<count, use (1<<31) | (1<<15). The extra noise from the 16-1 is significant. On seeing the -1, for the first half a second I expected it was going to be (1<<16)-1, but it turned out the brackets were different. As well as small powers of 2 being "well known", small 2^n - 1 is also easily recognized by humans. Writing 15 as 16-1 is just distracting and obfuscated, not helpful. Sometimes it can be helpful to write an expression in terms of subtracting two meaningful things, like cmp $'z'-'a', %al (although in practice 25 is just as if not more helpful to understanding the unsigned compare range check trick), but not here where -1 is not "meaningful". We already know that the top bit of a 16-bit number is bit 15 because we count bits from 0 (1<<0).

---

However, since this is x86-64, normally you'd use SSE2 pcmpgtw to check 16 bytes (8 words) at once against a zeroed register (created with pxor xmm0,xmm0), unless checking just a single pair is relevant.

To check pairs of words in a vector, you could pcmpeqd on the pcmpgtw result, to find dwords where both word elements produced a false (0) result.

x86-64's guaranteed support for SSE2 makes SWAR tricks with integer registers less frequently useful, but yes if you really do only have one pair to test, then integer is more efficient.