You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Basic support for floats (f16, f32, f64, f128) (#995)
This PR adds basic support for [IEEE 754 Floating Point
Numbers](https://en.wikipedia.org/wiki/IEEE_754), specifically `f16`,
`f32`, `f64`, `f128`.
These are already supported in K through builtins (see
[domains.md](https://github.com/runtimeverification/k/blob/master/k-distribution/include/kframework/builtin/domains.md#ieee-754-floating-point-numbers)).
This work is derivative of the implementation in the c-semantics (see
ieee754.k in that repository).
In particular:
- 6 tests are added that tests each type for equality, negation,
comparison, casting, arithmetic, and special values (NaN and Infinity)
- Documentation and helpers for floats are added to numbers.md
- Decoding is added for floats from bytes in numbers.md (see note on
haskell backend below)
- Semantic rules for arithmetic are extended for floats in data.md
### Haskell Backend
The haskell backend has no `Float` builtins (no Float.hs in
[kore/src/Kore/Builtin/](https://github.com/runtimeverification/haskell-backend/tree/master/kore/src/Kore/Builtin)).
This means `kore-exec` crashes with "missing hook FLOAT.int2float" when
attempting to evaluate a float. The booster avoids this by delegating
Float evaluation to the LLVM shared library via `simplifyTerm` in
[booster/library/Booster/LLVM.hs](https://github.com/runtimeverification/haskell-backend/blob/master/booster/library/Booster/LLVM.hs).
Prior to being able to decode floats, they were left as `UnableToDecode`
which did not throw and error in the exec-smir test suite for
`--haskell-backend`. Now that they are able to be decoded, the haskell
backend throws on these decoded values. So I am now skipping any tests
with decoded floats for exec-smir with haskell backend.
[preserves-definedness] // OP known to be a comparison
2149
2223
```
2150
2224
2151
-
The `binOpCmp` operation returns `-1`, `0`, or `+1` (the behaviour of Rust's `std::cmp::Ordering as i8`), indicating `LE`, `EQ`, or `GT`.
2225
+
Types that are equivlance relations can implement [Eq](https://doc.rust-lang.org/std/cmp/trait.Eq.html),
2226
+
and then they may implement [Ord](https://doc.rust-lang.org/std/cmp/trait.Ord.html) for a total ordering.
2227
+
For types that implement `Ord` the `cmp` method must be implemented which can compare any two elements respective to their total ordering.
2228
+
Here we provide the `binOpCmp` for `Bool` and `Int` operation which returns `-1`, `0`, or `+1` (the behaviour of Rust's `std::cmp::Ordering as i8`),
2229
+
indicating `LE`, `EQ`, or `GT`.
2152
2230
2153
2231
```k
2154
2232
syntax Int ::= cmpInt ( Int , Int ) [function , total]
@@ -2183,7 +2261,11 @@ The semantics of the operation in this case is to wrap around (with the given bi
2183
2261
...
2184
2262
</k>
2185
2263
2186
-
// TODO add rule for Floats once they are supported.
2264
+
rule <k> #applyUnOp(unOpNeg, Float(VAL, WIDTH))
2265
+
=>
2266
+
Float(--Float VAL, WIDTH)
2267
+
...
2268
+
</k>
2187
2269
```
2188
2270
2189
2271
The `unOpNot` operation works on boolean and integral values, with the usual semantics for booleans and a bitwise semantics for integral values (overflows cannot occur).
0 commit comments