Hacker News Reader

Comment by abenedic | Hacker News Reader

I have been doing a lot of assembly programming, and I can't help but agree with this. It is crazy how simple x86 assembly language programming makes checking overflow compared to C.

View on HN

> It is crazy how simple x86 assembly language programming makes checking overflow compared to C.

It's easy to write, but not so easy to optimize the performance.

Overflow checking creates a dependency in between operations and requires the emission of instructions that didn't have to be there before.

i += 1 <branch if overflow> i += 1 <etc>

Means that you are executing more than twice the number of instructions and are getting further behind on the dependency chain each iteration. Eventually, your branch subsystem is completely overwhelmed by a branch that is taken effectively never.

ish, you can use cmov for some stuff.

Where is it available in MIPS?

> cmov's can make a difference. You can use them to avoid polluting your branch prediction tables, you can use them to make code smaller, and you can use them when they simply just fit the problem really well. It's just _not_ the case that they are "obviously better". They simply aren't.

https://yarchive.net/comp/linux/cmov.html

If the upper bound is known, then we'll just make the check once before the loop, no?

That's the issue: while x86 exposes such operations, not all assembly dialects do. They too have to support C and emulating overflow detection in software would be unreasonable.

It seems to me that it would not be unreasonable. If you need that detection, you need it at any price, on any platform. If you don't need it, meaning, the code doesn't test it, the compiler has still the right to optimize it away.

So it would be implementation defined behavior. I'm fine with that; personally, I think the standard was too quick to assign "undefined" here. But it can't mandate a certain behavior in the standard across all platforms.

Reply on news.ycombinator.com