Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make int->float conversion a transmute #105

Merged
merged 2 commits into from
Nov 29, 2017

Conversation

Gankra
Copy link
Contributor

@Gankra Gankra commented Nov 15, 2017

This is the mirror commit to rust-lang/rust#46012

@Gankra Gankra force-pushed the float-transmute branch 2 times, most recently from 4673fc2 to f847070 Compare November 15, 2017 22:40
@Gankra Gankra changed the title make int->float conversion a transmute on x86/x64/ARM/aarch64 make int->float conversion a transmute Nov 15, 2017
@Gankra
Copy link
Contributor Author

Gankra commented Nov 15, 2017

Changed to transmute based on feedback on upstream Rust change.

Note that this basically gives us a cross-platform guarantee of if you feed in a NaN from one end, you get "some" NaN on the other end. The bits will match, but signaling-ness may toggle.

@BurntSushi
Copy link
Owner

BurntSushi commented Nov 16, 2017

@gankro Thanks! I think you need to update (or remove?) the read_snan test though, which was made to test the masking implementation.

The bits will match, but signaling-ness may toggle.

Could you say more about this? I don't think I understand. If the bits don't change, how does signaling-ness change? (Please keep in mind that my knowledge of floating point is quite simplistic.)

@Gankra
Copy link
Contributor Author

Gankra commented Nov 16, 2017

Basically until 2008, IEEE didn’t spec how to determine signalingness. Most platforms ended up picking the one that was later spec’d but e.g. MIPS picked the opposite interpretation of the signaling bit. So a signaling NaN on x86 is quiet on MIPS and vice-versa.

@Gankra
Copy link
Contributor Author

Gankra commented Nov 16, 2017

This leaves any protocol which wishes to communicate between two systems with different signaling interpretations with a choice: either guarantee the NaN payload is preserved, or guarantee the signalingness is preserved.

For various reasons signaling is a bit of a mess, so it’s hard for it to be useful, making my preference preserving the NaN payload (which is also the easiest impl: transmute on both sides).

@Gankra
Copy link
Contributor Author

Gankra commented Nov 16, 2017

If you prefer the other option, the "obviously correct" canonicalization is still the 2008 spec, which still makes almost every platform read/write with transmute. MIPS and the few other "rogue" platforms would need to check if the value is NaN and flip a bit on read/write (similar to the current reading code).

@BurntSushi
Copy link
Owner

@gankro Ah thanks for explaining that, I finally understand. Keeping it as a transmute is fine with me!

@BurntSushi
Copy link
Owner

(But this does still need to remove the snan test!)

@Gankra
Copy link
Contributor Author

Gankra commented Nov 16, 2017 via email

@Gankra
Copy link
Contributor Author

Gankra commented Nov 24, 2017

Accepted upstream, pushed test removal.

Copy link
Owner

@BurntSushi BurntSushi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @gankro! I have a couple of fixups to make and then I'll push out byteorder 1.2.

@BurntSushi BurntSushi merged commit fde8463 into BurntSushi:master Nov 29, 2017
BurntSushi added a commit that referenced this pull request Nov 29, 2017
BurntSushi added a commit that referenced this pull request Nov 29, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants