Casting to float32 on NimVM is broken

[johnnovak]

Example

import strutils

let u64 = 0xdeadbeefcafebabe'u64
let f64 = cast[float64](u64)
echo "*** runtime"
echo f64
echo cast[uint64](f64).toHex

let u32 = 0xdeadbeef'u32
let f32 = cast[float32](u32)
echo "*** runtime"
echo f32
echo cast[uint32](f32).toHex

static:
  let u64 = 0xdeadbeefcafebabe'u64
  let f64 = cast[float64](u64)
  echo "*** compile-time"
  echo f64
  echo cast[uint64](f64).toHex

#[
static:
  let u32 = 0xdeadbeef'u32
  let f32 = cast[float32](u32)
  echo "*** compile-time"
  echo f32
  echo cast[uint32](f32).toHex
]#

Current Output

With the last static block commented out as shown above:

*** compile-time
-1.188595878826402e+148
DEADBEEFCAFEBABE

. . .

*** runtime
-1.188595878826402e+148
DEADBEEFCAFEBABE
*** runtime
-6.259853398707798e+018
DEADBEEF

With the last static block uncommented the cast[float32](u32) statement fails. Note this only happens on NimVM and only with float32. All integer types and float64 are fine.

*** compile-time
-1.188595878826402e+148
DEADBEEFCAFEBABE
fatal.nim(64)            sysFatal
Error: unhandled exception: value out of range: 3735928559 [RangeError]

Expected Output

As explained above, casting to float32 on NimVM should work just like all the other numeric types.

Additional Information

Broken on v1.0.6 and on the latest dev build. Same results on Windows and OS X.

Nim Compiler Version 1.1.1 [Windows: amd64]
Compiled at 2020-02-23
Copyright (c) 2006-2019 by Andreas Rumpf

git hash: fdf5480afc7fc0952332b3d5bde9c6885100da3e
active boot switches: -d:release

[timotheecour]

is that related? #12884

[johnnovak]

It seems to be related, yes. Well, if there's no interest in making float32 available in NimVM that means bit-manipulations using floats are pretty much impossible...

[timotheecour]

Well, if there's no interest in making float32 available in NimVM

there is but it's hard, see my attempt #12906

[krux02]

@timotheecour no, #12884 is not related.

@johnnovak Well, there is actually no interest to make true float32 available in NimVM. There is the type float32, bit internally it has 64 bit precision. It is kind of a distinct float64, but without using the distinct keyword. That is mostly done to be able to execute code that uses float32 on the VM as well, but float32 is not a type that is recommended to be used for VM code, it only works there. Maybe you can elaborate a bit more on your plans that you see to not work out.

BTW if you compile nim with koch boot -d:danger this bug will disappear. This bug is caused by a range check that doesn't exist in "danger" mode.

[johnnovak]

@krux02 It's just that I can't do endianness conversions on float32 types in the VM then. See here: #13463

Which also means that my upcoming binstreams module (endianness aware streams) that otherwise will support NimVM won't be able to read float32 values from streams.

Not a huge problem I think, not too many people will want to use endianness-aware I/O at compile time, but still an annoying limitation. But yeah, probably there's more important things on the priority list if this is hard.

[timotheecour]

Vmops.nim is always possible as last resort

[krux02]

@johnnovak well concatenating 4 bytes into a float32 should work at compile time the same way as at runtime. It is just that after thas casting conversion the actual value will be stored with 64 bit precision. So you won't have any memory advantage from using float32 over float64 at compile time.