01041018 3D FF 00 00 00 cmp eax,0FFh (1 clock) 0104101D 77 06 ja main+25h (1041025h) (1 clock)
I also checked this in 64-bit, and it is the same instructions. In the suggested approach, we have an extra movzx, and it consumes a register, which would tend to cause surrounding code to optimize less efficiently on x86 (probably negligble on x64, but
same effect). Due to the movzx being expensive (relative to cmp), the suggested approach is 6 cycles to the current approach's 2 cycles, or 3x worse. If the surrounding code were register constrained, as x86 often is, then you might need to push something
on the stack to free a register, which would be more overhead.
To be fair, I chalk this up to pure, blind luck. While I did try to write the code to be as efficient as possible, readability and correctness were of higher importance. It is entirely possible that other operations may not be as efficient as possible. I
think I did try to avoid temporary variables where possible, for just this reason, though in some cases it couldn't be avoided, and the effect would often be diluted by how expensive large multiplication and division operations are.
A large chunk of work that has not yet been done is to take all 64 combinations for each and every operation type and see exactly how they optimize, and dink with it to see if it can be better. As an aside, we considered using intrinsics for x64 multiplication,
which would have been a lot faster, but decided not to in this release due to schedule constraints.
In addition, unless you happened to be using SafeInt inside of a rendering engine, or something else where a couple of cycles matter, a couple of cycles here and there are not going to add up to anything, considering that an allocation could cost several
10's of thousands of cycles, loading a COM object is much, much bigger, and so on.
Thanks for the question - I got to learn a bit about assembly that I didn't know before today.