Comment by tialaramex
2 days ago
Exactly, if I write a Rust function which is actually wrapping the Intel ADD integer addition on 64-bit registers but I give my function floating point types (f64) instead, the CPU merrily performs the integer addition even though that's "wrong" in some sense.
I don't have Bill's brand new nightly Odin compiler with "assembly templates" but I don't really see any useful way it could "fix" this. The machine does not care what your values "mean" to you, that's a human idea and that's what types are for.
Actually that case might be caught, depending on the architecture. E.g. on RISC-V float and integer registers are separate and the compiler would fail if you tell it you want an integer register and you try to load that with a float.
That's his "aha, they are typed!" gotcha, but it's really not what anyone was talking about. And anyway, even in that case it isn't guaranteed - RISC-V has an optional configuration where float and integer registers are the same.
I was aware that some architectures had distinct floating point registers but I didn't know RISC-V is / could be one of them. As RISC-V becomes more popular perhaps I should consider choosing a different example for where typing evaporates to produce zero machine code during compilation, today I'd cite f32::to_bits which takes a 32-bit floating point value and gives us a 32-bit unsigned integer but maybe I should use u32::cast_signed since having distinct registers for signed versus unsigned integers is surely rare.
> I was aware that some architectures had distinct floating point registers
Most ISAs do.
On x86 and arm scalar and FP registers are separate, it's just that they overlap FP and SIMD registers.
On RISC-V there are three separate register files for scalar, FP and SIMD. Although you can overlap scalar and FP in some minimal embedded configurations.
1 reply →