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

[Feature] Add native support for other floating point types #1864

Open
1 task
BobSmun opened this issue Aug 23, 2024 · 3 comments
Open
1 task

[Feature] Add native support for other floating point types #1864

BobSmun opened this issue Aug 23, 2024 · 3 comments

Comments

@BobSmun
Copy link

BobSmun commented Aug 23, 2024

What feature would you like to see?

In order to have closer parity with the existing supported integer types, it would be helpful to have access to other common floating point types such as 16 (half-precision), 80, and 128-bit (e.g. long double) types. These could then also have typedefs such as f16, f32, f64, f80, f128 (for parity with e.g. u128, etc)

This extended support would also apply to the PatternLanguage, but raising the feature request here as the editor as a whole also benefits from the suggestion.

Given how many variations there are (primarily differing only in exponent and mantissa lengths), perhaps a generic / templated type would also be feasible.

How will this feature be useful to you and others?

  • Some of these types are available in gcc - at least - see: https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
  • Half-precision is used in many computer graphics formats to store pixels, in machine learning models, etc
  • Current Unix time does not fit at nanosecond resolution in a regular (64-bit) double, so (128-bit) long double might get used instead

Request Type

  • I can provide a PoC for this feature or am willing to work on it myself and submit a PR

Additional context?

No response

@paxcut
Copy link
Contributor

paxcut commented Aug 23, 2024

What do you mean by having access to half floats and the other types? Math co-processors only support floats and doubles. 80 bit floats are only supported internally to ensure calculations have full precision results. Wouldn't support for types other than floats and doubles require that operations that use those types would have to be emulated? Would that still be considered as native support? From what I remember, and I may be wrong about this, all the types that ImHex supports are gcc supported types.

If you encounter floating point numbers that are not natively supported you can calculate their values with the help of the ieee 754 floating point encoder and decoder tool provided in View>Tools which allows you to find how ieee 754 defines floating point numbers for any number of bytes, exponent size and mantissa size combination. Once you know how the numbers are encoded you would need to write functions to do the actual conversion but the tool makes it easy to write such functions not only for decoding but for encoding as well.

@BobSmun
Copy link
Author

BobSmun commented Aug 23, 2024

I should have said 'built-in' instead of 'native'. The intention being to allow built-in access to the other IEEE-754 binary interchange formats (adding 16-bit and 128-bit, at a minimum) without needing to define / use custom patterns for them in PL - like the float16.pat already available. That is to say, this request is less about platform support and more about tool support and consistency

I can see that Data Inspector already has half float (16 bit) and long double (128 bit), but this support isn't consistent throughout ImHex. For instance, View > Tools > IEEE 754 ... does not seem to have support for anything above 64-bit [and wasn't originally the intention of this request, but changes to expand that tool could certainly fit here]. Although this encoder / decoder tool is great, and covers 'templated floating point' from a UI standpoint (size limitation just mentioned notwithstanding), the point about feasibly having a generic / templated type was more of a side note aimed a little more towards the pattern library
e.g. something like the following, would be neat:

import ieee_754;

// this specifically could possibly be pre-defined in ieee_754 as fp256
// (to disambiguate from any potential future f256 being added to built-in)
using binary256 = ieee_754::binary<19, 236>;

I put this request here, instead of under either of the the PL focused repos, to focus more on ImHex as a whole
e.g.

  • the code appears to use double (64-bit) as the underlying floating point storage type in many places, which isn't consistent with the 128-bit integer types being used in equivalent places
  • adding / using f data types in pl and code (f16, f32, f64, f128), to align with existing u and s data types (like u128)
    • For instance, Edit > Place Pattern ... > Built-in Type > [here], replacing float and double currently there

P.S. I did list 80-bit originally, because the linked gcc page made specific mention of supporting __float80 (aka _Float64x apparently), but admit that it is probably esoteric enough from a

@WerWolv
Copy link
Owner

WerWolv commented Aug 23, 2024

I plan on adding the remaining built-in float types once there's wide support for C++23's stdfloat. Once that's there, I'll leave float and double as the "system specific" float implementations and add f16, f32, f64, f128 and probably bf16 using their standard library implementations that are guaranteed to be IEEE754.

There's a 16 bit float implementation in the type library right now that can be used but that's of course not as performant as doing it natively. I would however still be open to have a generic floating point implementation in the type library as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants