3 ms·
But that's trivially solvable (on x86 at least). You do your arithmetic in rax and then compare the result in eax. You've got the "mask the high 32 bits" operat
by Asooka 8y ago
But that's trivially solvable (on x86 at least). You do your arithmetic in rax and then compare the result in eax. You've got the "mask the high 32 bits" operation for free. At worst you'll need to do one bitwise and before using the value for cases where the high bits being poisoned matters. Or let me add annotations to arithmetic expressions that "this expression will definitely not need expensive cleaning up afterwards, promise", which I will need to use in maybe a dozen super-hot loops in the whole codebase. FWIW, we compile all our code with -fwrapv and don't notice any slowdown.
- Someone 8y ago”But that's trivially solvable (on x86 at least)” Even if that’s true (I don’t know enough of x86 assembly to judge that, but one thing I can think of that it may require extra register-to-register moves), that it isn’t an issue for one architecture won’t help a committee discussing the C standard. Also, others in this thread describe what you call “let me annotate” as “forking C”.
- BeeOnRope 8y agoOf course it's trivially solvable in x86-64 because it has a full complement of 32-bit operations inherited from its x86 lineage. The GP is presumably talking about _other_ architectures when he mentions designs that might not want to add a full complement of 32-bit operations. In any case, the problem doesn't really apply to x86 because all x86 compilers I'm aware of use the "expected" size for the various types rather than larger-than-needed-for-speed, exactly because the smaller operations are all generally available.