Stream: compiler development

Topic: compile-time evaluation

Richard Feldman (Aug 26 2023 at 20:36):

regarding @Folkert de Vries's comment in the meetup about compile-time floating-point answers differing depending on what hardware they happened to be run on: here are a couple of C floating-point software emulation libraries that could be used for emulation

• Berkeley SoftFloat - BSD licensed
• GNU MFPR - LGPL licensed

Brendan Hansknecht (Aug 26 2023 at 23:04):

Weird part about that is it may still lead to unexpected results for end users. Cause even though you now have consistently defined results, you no longer are doing what is expected of hardware. So a user who only runs on one hardware and expects hardware results may not get what they expect.

Brendan Hansknecht (Aug 26 2023 at 23:04):

On top of that, what do we do about the extra flags you can set around rounding and such.

Richard Feldman (Aug 27 2023 at 18:34):

so my overall thought is:

• if you're using floats, it's because you need the runtime performance. Otherwise, use Dec.
• an unfortunate cost of this runtime performance is that you get inconsistent results; answers may differ by system because different CPUs implement the standard slightly differently, and/or may have extra instructions that make certain operations go faster but which give slightly different answers (and aren't available on other CPUs). As far as I can tell, this is an unavoidable cost of doing business with floats; there's no way to get the performance without those inconsistencies.
• with that in mind, "I got a slightly different answer than I expected" seems like it should be acceptable. If you need precision, floats are not acceptable for your use case.
• that said, it should be an ironclad guarantee of the language that if you take the same source bytes and compile them on any Roc system with the same roc flags (e.g. --target), you should get the exact same bytes out the other side, maybe give or take metadata like the timestamp of when it was built or something like that.

Richard Feldman (Aug 27 2023 at 18:36):

so the problem I'm interested in solving is reproducibility - I wouldn't want compile-time floats to give a different binary on my local machine vs on CI (again, maybe give or take metadata like timestamps, but I think it's possible we end up wanting to eschew timestamps like that because bit-for-bit reproducible binaries might be more valuable than those) even if my local machine has a different CPU architecture than my CI does

Brendan Hansknecht (Aug 27 2023 at 21:54):

Sounds good. Just wanted to check if the slowness of software floats was worth it. Maybe we can make it so software floats are only needed if you cross compile. If you compile for the host target, you can just set the flags to the hardware mode we want and use hardware floats?

Brendan Hansknecht (Aug 27 2023 at 21:55):

So consistent and often able to be fast at least for targets with the same float unit(though I don't know all of the hardware intricacies)

Brendan Hansknecht (Oct 21 2025 at 19:15):

I think it may be running on all assignments?

This is inside of a function

-- COMPTIME EVAL ERROR ---------------------------

This definition could not be evaluated at compile time:
    ┌─ chip8_test_rom.roc:332:20
    │
332 │             xIdx = opcode.bitwiseAnd(0x0F00).shiftRightBy(8)
    │                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The evaluation failed with error:
    TypeMismatch

This is top level and just a surprising failure.

-- COMPTIME EVAL ERROR ---------------------------

This definition could not be evaluated at compile time:
  ┌─ chip8_test_rom.roc:3:9
  │
3 │ width = 64
  │         ^^

The evaluation failed with error:
    TypeMismatch

Brendan Hansknecht (Oct 21 2025 at 19:16):

Given roc check passes, I'm pretty sure tat TypeMismatch is impossible. So kinda a funny error to see roc spit out.

Richard Feldman (Oct 21 2025 at 20:30):

yeah it's supposed to evaluate inside functions too

Richard Feldman (Oct 21 2025 at 20:32):

basically everything that can be evaluated at compile time (which means it doesn't have any dependencies on fn args that are only known at runtime) is supposed to be evaluated at compile time

Richard Feldman (Oct 21 2025 at 20:33):

otherwise moving the same definition from top-level to an inner scope could degrade performance, which in turn would mean deciding which scope to put constants in would have performance implications instead of just scope visibility implications, which would be really undesirable :sweat_smile:

Richard Feldman (Oct 21 2025 at 20:34):

all that said, this seems like a bug (or at least a confusing error message) - any chance you could get a test reproducing it?

Richard Feldman (Oct 21 2025 at 20:34):

doesn't even have to be super minimal, just something I can try out

Brendan Hansknecht (Oct 21 2025 at 21:02):

This is just roc test on the chip8 file from the other thread

Brendan Hansknecht (Oct 21 2025 at 21:03):

File here: https://github.com/bhansconnect/chip8_op_test/blob/main/chip8_test_rom.roc

Brendan Hansknecht (Oct 21 2025 at 21:05):

Also, I guess given this is part of roc test, technically the entire thing is known at compile time. But generally, most of the errors here would not be know at compile time.

Last updated: Nov 08 2025 at 12:13 UTC