Hacker News Reader

Comment by ajross | Hacker News Reader

The "real" bug here is Motorola's. Having instructions that fail silently (vs. trapping, as DIVU actually does if the divisor is zero!) is just outrageous.

For clarity, because the article takes too long to get there: DIVU has a 32 bit dividend, but a 16 bit divisor and a 16 bit result. So if you try to divide e.g. 0x20000 by 2, the result should be 0x10000, which doesn't fit in the output register. So... the CPU sets the overflow flag but otherwise does nothing!

I'm not quite old enough to have been writing assembly for the 68k, but I've heard this issue before. This was surely not the only footgun situation with DIVU in the market.

View on HN

The rationale probably is that you can easily check for division by zero before doing the actual division, whereas checking for an overflowing division requires to actually perform the division. The DIVU instruction thus allows to check for overflow without the overhead of raising an exception.

It certainly is a bit of a footgun, because one normally doesn’t expect overflow on integer division. On the other hand, the other basic arithmetic operations all require overflow checks as well, or equivalent operand value analysis. And this is assembly we’re talking about, where you’re supposed to know what you’re doing.

If it's documented it's not a bug, it's behavior.

The developer should check for overflow before using the value. If this assembly is compiler generated then it's probably classifiable as a compiler bug.

A spec bug is still a bug from the user's perspective.

I would disagree. At the assembly level, as long as the instruction documents what it does in the oddball cases, it's up to you the programmer to use it correctly. Some CISC CPUs trap on errors like divide-by-zero; RISC instruction sets usually make the choice to define some specific behaviour. (For example on Arm, division by zero will always return a 0 result, and will not trap.) Taking an exception is an expensive business, and if the programmer wasn't expecting it then the result will be no better (program crashes, instead of program hangs).

> on Arm, division by zero will always return a 0 result, and will not trap.

Cortex-M and -R have support for div-by-0 faults but it's disabled by default.

It's not really failing silently, it's telling you through the overflow flag. To me this seems logically consistent with how one would expect overflow to behave, as it does with other instructions like ADD.

That said, I think this instruction would be safer and more useful if it still set at least the remainder result bits (which should always be valid). Then this case would not require checking, as would some other common cases like 'execute every odd iteration' kind of code.

Does ADD on m86k leave the output unchanged or truncate? If division truncated the multiplication result then the moduls would still be usable and this bug would not have happened. Not performing the operation at all on overflow but not raising a fault is odd behavior to say the least.

That may be a better choice, but it wouldn't have prevented the bug from the article, would it? Because at the time of release, the date didn't overflow. And after their goofy "subtract 5,000 days" fix, it didn't overflow either. The only change would be the user experiencing a crash vs a hang.

Reply on news.ycombinator.com