Division by zero [LWN.net]

Division by zero

Posted Jan 4, 2025 13:06 UTC (Sat) by pizza (subscriber, #46)
In reply to: Division by zero by pm215
Parent article: Preventing data races with Pony

> But the CPU architecture you're next most likely to be running on today (arm) does not.

Historically, Arm processor didn't actually implement a hardware integer divider, so any faults/exceptions had to be triggered by the low-level software runtime library.

But starting with armv7-m and armv8, there are integer divide instructions, and they can generate divide by zero exceptions -- something I can personally attest to triggering numerous times. Here is the documentation on the UDIV/SDIV instructions on armv7-m:

https://developer.arm.com/documentation/ddi0403/d/Applica...

Meanwhile, IIRC the various Arm FPUs always supported faults/exceptions, including for divide-by-zero.

to post comments

Division by zero

Posted Jan 4, 2025 18:03 UTC (Sat) by khim (subscriber, #9252) [Link] (4 responses)

> But starting with armv7-m and armv8, there are integer divide instructions

Yes.

> and they can generate divide by zero exceptions

No. Take your own link that, with one click, tells us how SDIV works on ARM 7-m. It looks like this:

if ConditionPassed() then
    EncodingSpecificOperations();
    if SInt(R[m]) == 0 then
        if IntegerZeroDivideTrappingEnabled() then
            GenerateIntegerZeroDivide();
        else
            result = 0;
    else
        result = RoundTowardsZero(SInt(R[n]) / SInt(R[m]));
    R[d] = result<31:0&rt;

Now compare that to ARM8 specification:

constant bits(datasize) operand1 = X[n, datasize];
constant bits(datasize) operand2 = X[m, datasize];
constant integer dividend = SInt(operand1);
constant integer divisor = SInt(operand2);
integer result;
if divisor == 0 then
     result = 0;
elsif (dividend < 0) == (divisor < 0) then
     result = Abs(dividend) DIV Abs(divisor); // same signs - positive result
else
     result = -(Abs(dividend) DIV Abs(divisor)); // different signs - negative result
X[d, datasize] = result<datasize-1:0>;

See that call to GenerateIntegerZeroDivide? I don't see it either.

Just why ARM decided that embedded version have to have “division by zero” exception while “big” CPUs have to silently produce zero is good question, but that's how things work currently.

P.S. Of course if you recall that RISC-V does things differently and x86, too… then question of codifying ARM-specific behavior in the language arises… but I guess it one of these “looked good at the time” ideas.

Division by zero

Posted Jan 4, 2025 18:10 UTC (Sat) by dskoll (subscriber, #1630) [Link] (1 responses)

Huh, you are right! Even though my Pi 4 is running an aarch64 kernel, userspace is 32-bit armhf and the test program raised SIGFPE. I tried the test program on a fully 64-bit Pi 4 with 64-bit userspace and it ran without complaint, assigning 0 to z.

Division by zero

Posted Jan 4, 2025 20:34 UTC (Sat) by pm215 (subscriber, #98099) [Link]

My guess is that your compiler is generating code that assumes the CPU doesn't implement the division instructions (because armhf includes v7-without-VE CPUs in its remit) and instead calls into the gcc runtime, and the runtime function is then manually raising a SIGFPE. (Possibly also the compiler figures out that it is a div by zero and generates a call to the div-by-zero runtime function.)

You can probably pass the compiler some kind of -march or -mcpu options to tell it to generate code assuming the v8 CPU you have, and then it ought to emit the udiv or sdiv inline, if you want to look at the behaviour in that situation.

Division by zero

Posted Jan 5, 2025 0:05 UTC (Sun) by pm215 (subscriber, #98099) [Link] (1 responses)

Re "codifying ARM-specific behavior in the language", it isn't necessarily that. The Pony FAQ justifies why you would want it to return *some value*, and having it return a known value rather than a random one is sensible for reproducibility. Then, you could pick anything, so why *not* 0? It makes no difference to the "branch away if divisor is zero" code you need to generate (and if you're really into shaving cycles then 0 has the advantage that you know for certain you already have it in the input value so you can copy it to the output and don't need to emit code to generate a fresh constant value).

Apparently various theorem provers also define their division this way:
https://xenaproject.wordpress.com/2020/07/05/division-by-...
and https://www.ponylang.io/blog/2017/05/an-early-history-of-... suggests that the inventory of Pony has some background in that kind of academic type theory/theorem proving area, so it seems plausible that the motivation for choosing 0 might been influenced by existing languages like that. Early 2010s seems a bit early for it to be very likely that a language designer was much influenced by fine details of codegen for Arm.

Division by zero

Posted Jan 6, 2025 0:38 UTC (Mon) by Heretic_Blacksheep (guest, #169992) [Link]

Mathematical correctness doesn't matter here because division by zero is undefined. You can literally make it anything you want - and I've seen math professors do so as an esoteric joke. However, programmers do not like non-deterministic error states. Pony makes the outcome deterministic, regardless of hardware traps that may or may not exist, allowing for a simple error check state across all architectures which the programmer can define as fatal or non-fatal depending on their program logic then handle it accordingly.

Given the alternatives, I'd much rather have a 'mathematically incorrect' deterministic result that I can take to the bank rather than depending on disparate architectural dependent error states that are really just as mathematically arbitrary as assigning X/0 == 0 but a lot more messy to deal with.

Division by zero

Posted Jan 4, 2025 20:19 UTC (Sat) by pm215 (subscriber, #98099) [Link]

Integer divide in A-profile comes in with the Cortex-A15 and A7, in v7VE, so some v7A cores have it, just not all. V7R requires it for the Thumb insn set but not the Arm one (!)

And yeah, as noted in the sibling comments M-profile has configurable trapping of integer division by zero, but A profile does not. (M profile diverges from A in various more or less obvious ways.) R profile also permits configuring trapping on div by zero. A profile never traps.

The v7A/R Arm ARM has a section that describes the various options:

https://developer.arm.com/documentation/ddi0406/c/Applica...

v8 got to clean this up by just having them be always present.

Division by zero

Posted Jan 4, 2025 20:54 UTC (Sat) by pm215 (subscriber, #98099) [Link]

By the by, on the floating point side of the house Arm has always supported setting the appropriate floating point status flag bit for fp division by zero, since this is a requirement of IEEE 754. Support for trapping (i.e. generating a CPU exception into the kernel instead of setting the status flag bit) is an implementation defined choice, though -- not many implementations choose to implement it (though I'm aware of at least one which does). As far as I know the only way to detect trapping support is to write a 1 to the FPCR/FPSCR "enable traps for this exception" bit and see if it reads back as zero or one -- if the implementation doesn't implement trapping then the bit will be RAZ/WI.