RMM rounding mode doesn't work correctly

[spholz]

The issue

This SerenityOS fenv test currently fails in RVVM, but works in QEMU:
https://github.com/SerenityOS/serenity/blob/bdfa78e487389293abc79dbb0ee9c082e8b03595/Tests/LibC/TestFenv.cpp#L81

Steps to reproduce

I made a reduced test case that prints "1" in QEMU and Spike, but "0" in RVVM:

test.s

.global _start
_start:
    fsrmi 4

    flw ft0, .LC0, t0
    flw ft1, .LC1, t0

    fadd.s ft2, ft0, ft1

    flw ft3, .LC2, t0

    feq.s t0, ft2, ft3

    bnez t0, correct

    li a0, '0'
    li a6, 2
    li a7, 0x4442434E
    ecall

1:
    wfi
    j 1b

correct:
    li a0, '1'
    li a6, 2
    li a7, 0x4442434E
    ecall

1:
    wfi
    j 1b

.LC0:
    .float 1.0
.LC1:
    .float 5.9604645e-08
.LC2:
    .float 1.0000001

You can build it using

riscv64-elf-as -march=rv64gc -o test.o test.s && riscv64-elf-ld -o test test.o && riscv64-elf-objcopy -O binary test test.bin

and then run it in RVVM with (assuming an OpenSBI build dir at $OPENSBI_BUILD)

rvvm_x86_64 $OPENSBI_BUILD/platform/generic/firmware/fw_jump.bin -k test.bin

and in QEMU with

qemu-system-riscv64 -nographic -kernel test.bin

[LekKit]

Okay, that's actually a problem that I'm not sure how to fix, because I am using native host FPU, and the host (x86, for example) simply doesn't support RMM rounding.
This is also noted in your tests at https://github.com/nico/serenity/blob/787f7dd84a7af7b54be75f045fe5d9c1c75aa896/Tests/LibC/TestFenv.cpp#L116.

I did not foresee this problem would arise in practice, and now all FPU instructions are simply dispatched to their host equivalents without a way to natively select RMM rounding. QEMU does all FPU computations in software, so it's probably a sound idea to execute FPU differently when rm = RMM. I'll see what I can come up with.

[LekKit]

It is probably possible to emulate round-to-max-magnitude via rounding to positive/negative infinity based on the output sign, or force the output sign to be positive during computation, and then recompute it back in software. That's probably not too much overhead (Except having to check for rm = RMM on the fast path).

[spholz]

I mean it might not be that big of a deal. I don't think RMM will be used much in practice since only RISC-V supports it.

It just means that this test doesn't pass. Though it would be nice to have all serenity tests pass in RVVM, so I can use it instead of QEMU for testing.

(I accidentally used nico's fork in the URL, but the same thing also happens in the main repo.)

[LekKit]

Should be fixed by 9c8999e

[spholz]

Hm, now this test works, but two other max magnitude rounding tests are failing:

I could also give you a reproducer for that or you could run this specific test with /usr/Tests/LibC/TestFenv in serenity yourself.
There are unofficial prebuilt serenity images available at https://filmroellchen.eu/services/serenityos/#artifacts if you don't want to build it yourself. You can run them like this:
rvvm_x86_64 $OPENSBI_BUILD/build/platform/generic/firmware/fw_jump.bin -k Kernel.bin -i _disk_image -m 2G -cmdline 'serial_debug root=nvme0:1:0'
(these unofficial builds don't have UEFI disk images at the momement.)

[LekKit]

Yeah so apparently RMM is not the same as rounding towards negative/positive infinity away from zero. The spec caught me off guard: "Round to nearest, ties to max magnitude", what does that even mean? If there is no proper matching rounding mode in other ISAs, it's hard to reason how should this even be emulated without soft floats.

@purplesyringa Maybe you have an idea about this? Thanks in advance.

[purplesyringa]

This reads to me as if a is right between two representable floats, you round away from zero, otherwise you round to the nearest float. ARM calls this mode "Round to Nearest with Ties to Away", though it only supports it for a select few operations that probably aren't of interest to you.

This is mainly ugly because CPUs don't expose any way to recognize whether there was a tie. For example, if some CPU supported both a round-to-nearest-with-ties-to-even and a round-to-nearest-with-ties-to-odd mode, we could compare their result to know if there was a tie, but I don't think any ISAs actually support such a rounding.

For floats at least, we can use the following workaround:

• Cast the inputs to doubles and perform the operation in double precision, rounding to nearest with arbitrary tie resolution.
• If the result is exact and the extended bits of the result's mantissa (i.e. bits added by the extension) spell 100...000, you know computing in floats would tie here. Convert the result to float while rounding away from zero and return it.
• Otherwise, floats wouldn't tie (even if doubles might), so just redo the calculation in floats and return that. Importantly, you can't just cast the double result to float here, since the mantissa may say 100...000 despite the calculation being inexact, in which case you'd get rounding wrong. Just compute twice.

On x86, you can use the FPU to handle doubles as well, but for ARM you'll need something trickier. I don't see an easy solution, so here's a difficult one:

• For addition and subtraction, use Kahan's summation to get a rounded result (to nearest, arbitrary ties) and an error.
• For multiplication, fma(-a, b, a * b) should give you the error.

I'm frankly not sure if these errors are exact, maybe you know more about this, but assuming they are: if the error is exactly +- 0.5 ulp of the true result, you know there was a tie, and you even know its direction, so you can counteract it and round away from zeros. Otherwise, the result is already correct. Note that I said 0.5 ulp of the true result, not of the rounded result, since rounding can change the exponent and thus ulp, so you need a correction if the error is away from zero and the result is a power of two. Maybe subtract 2 * error or something?

I'm not sure what to do for division, since the exact error is unrepresentable. Maybe you can compute c = a / b rounding down, get fma(b, c, -a) to compute the error for this approximation, fma(b, next(c), -a) to compute the error for rounding up, and then choose between them based on whether the errors are the same or one is smaller than the other. But I think fma is not guaranteed to be exact here, so this might just fail. This needs more thought put into it.

[SolAstrius]

Fixed in #239.

[spholz]

Note that we (serenity) removed support for FE_TOMAXMAGNITUDE (RMM) in SerenityOS/serenity@f969960, so you have to revert that commit if you want to use our test cases.