I want to quickly recognize whether AL has a zero bit in each tetrad. I.e.

AL=11110001 not
AL=00000000 yes
AL=01111111 not
AL=00111011 yes
...

Is there a method faster than xlat?

TIA,
Serge

Every machine will be different. Yes, really. You will have to test a range of possible solutions on the target machine to determine which is "fastest" for that machine.

Also, it is probably worthless to test only sample code. You should try to test the entire code and see which option(s) work best when the whole application is running.

I had to Google what "tetrad" means (maybe I suck ) but this is usually called a "nibble" (4-bits).

The "pattern" here is that either the number mod 16 is 15, or it is higher than 239, it's the only time it will give out the answer "no". I'm not sure if you can use "ah" (i.e. rest of eax) as you didn't mention it, but if you can, let's assume ah is zero, try something like: The first one produces a carry into ah if the number was 239 or greater, which means "no" (since 239 mod 16 is 15, and >= 240 is the other condition for "no"). The addition places the carry into ah. Then we decrease ah, resulting in all 1s if there was no carry, and zero otherwise. We then "mask" the resulting al with this: if carry, set al to zero.

Then we test for low 15 bits to see if they are zeros -- because they are zero only if they were 15 (we added '1' to them when we did first addition, that's why "16+1") or if the carry was produced (it zeroed al). Meaning they should be zero if number was >= 240 or if low 4 bits were all 1s.

I only wanted to use one branch for obvious reasons. I have no idea if it's faster than a lookup table though, but you can't test if there is no alternative

Furs: That is a great analysis. But is it faster?

I don't know, it probably is in some cases (it depends on surrounding code, since otherwise if branch gets predicted properly all the time it doesn't matter which one you use), probably not in others etc.

But still you need "different" ways to be able to test them, can't test something when you don't even know alternative

Furst: I think your first two instructions may be contracted to:

I was worried about the carry going into the al but it seems you are right! I just tested it, so now it's: I think now it's definitely "faster" or at least the "same" speed. Also much more friendly to the cache (no need for a lookup table using 256 bytes).

Well, we could just use 0FF00h instead of "(-1) shl 8" and then forget about carry (it would land in the high part of EAX that does not concern us).

It probably uses more bytes in the instruction cache, but fewer bytes in the data cache. Maybe it is "faster", maybe not. We would need the OP to test it.

Because this is just a yes/no test, you could even try BT instead of XLAT. Lookup table would then be 32 bytes instead of 256.

Yeah but AFAIK bt with "mem, reg" operands is super slow. (only that combination)

This one does not need to assume an initial value of ah and seems almost 2 times faster on my machine (not taking the branch into account):

lahf may be unavailable in 64-bit mode on some machines and may also be slower on some other machines.

Nice, I completely forgot that the Auxiliary Flag even exists.

BTW without using the Auxiliary Flag trick, I realized you don't have to assume or touch the upper parts of eax, as long as you know 'ah' is zero. i.e. My brain wasn't functioning correctly yesterday here. I mean, we're only interested in zeroing the lower 4 bits, don't care of the others.

Sorry, I'm not an English speaker. Google Translate gave me two results: tetrad and quaternion.

Thanks, but I wrote my naive test and this test works faster than both above examples (on my Athlon II X2 under Win32).

With random values? Two branches would be much worse in a non-simulated test, at least on newer CPUs, but I have no idea about Athlon II. I mean, make sure you test it with "reasonable" values you can expect in the program etc.

With two branches tell me if the following is faster on your CPU? (no need for ah at all)

Make your tests in the real code. No amount of simulation will help IMO.

@_shura You meant to use "test" right? Now the second one will always be 0. test is also better as it can micro-fuse on newer CPUs with the branch (speed may be the same, but it's one less micro-op, which can help in other situations).

I doubt it's faster than the add+jc I posted (also two branches) even on Athlon which probably doesn't even do micro-fusing (because add->jc is probably not micro-fused since it's not very "common" like test/cmp + branch) since it has 1 more insn so (at least) 1 more micro op.

nobody said al had to contain the initial value
what about