#nan #pointers #tagged-pointers #nanbox #tagged-enum

no-std litl-nanval

A 64-bit value, that is either a floating-point number (f64), or an arbitrary 52-bit integer

1 unstable release

0.2.0 Nov 15, 2022

#10 in #tagged-pointers

Download history 28/week @ 2024-07-22 27/week @ 2024-07-29 27/week @ 2024-08-05 17/week @ 2024-08-12 15/week @ 2024-08-19 64/week @ 2024-08-26 13/week @ 2024-09-02 15/week @ 2024-09-09 22/week @ 2024-09-16 54/week @ 2024-09-23 13/week @ 2024-09-30 4/week @ 2024-10-07 23/week @ 2024-10-14 9/week @ 2024-10-21 9/week @ 2024-10-28 12/week @ 2024-11-04

53 downloads per month
Used in 11 crates (via litl-val)

MIT/Apache

26KB
430 lines

nanval

Crates.io Docs.rs GitHub LOC

A no_std, zero-dependency crate for the creation and handling of NaN-tagged values.

Inspired by this article and this crate.

How does this work?

When a 64-bit floating-point number is set to NaN/0x7FF8000000000000, its bits are as follows:

s111 1111 1111 1qxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
^               ^\____________________________________________________________/
|               |                             ^
| Sign Bit      | Quiet Bit                   | Data Bits

As long as the data bits aren't all set to 0, indicating the original/sentinel NaN value, they can be literally anything else! This gives us 50 bits to mess with/use as we please...

UInts / Unsigned Integers

Look at the module crate::uint for this.

TODO: Add explanation.

Cells / Pointers

Look at the module crate::cell for this.

Since it doesn't matter what the sign-bit s is set to, we can use it as a flag/marker that indicates that the value is some kind of cell or ptr.

Combine this with the fact that basically all x64-platforms only use the lower 48 or 50 bits for addressing (ignoring CHERI shenanigans), we are left with 3 bits (that includes the 'quiet' bit) to store some kind of type-tag for the cell; look at the crate::cell::CellTag.

References

No runtime deps

Features