Nothing in particular prevents these from being constexpr. Do so to make
them consistent with the bulk of other functions in this header that are
constexpr.
Negation in (standard IEEE) floating-point is simply flipping the sign-bit, so this
operation will never be more complex than what is presented here, making
constexpr a reasonable allowance.
While initially done to potentially prevent creating bugs due to C++
having a silly type-promotion mechanism involving types < sizeof(int)
and unsignedness, given that the bulk of these functions' usages
are on exit paths, these can return the correct type to avoid the need
to cast at every usage point.
Due to promotion rules (types < int, even if unsigned, get promoted to
int when arithmetic is performed on them), this is a potential spot for
undefined behavior.
This is supposed to call FPUnpackBase instead of FPUnpack. This would
result in alternate half-precision representations being misinterpreted
when it comes to dealing with NaNs.
Avoids potentially clobbering the intended sign bit value during
conversions to double-precision values. The other conversion types are
already properly handled, so those don't need to be addressed.
This corrects one case where floating-point exceptions could be set when
they're not supposed to be.
This also corrects a case where values were being treated as NaNs when
they weren't supposed to be.
This function is defined as always disabling the AHP bit in the fpcr
before performing any operations.
At the same time, rename the original FPUnpack function to FPUnpackBase
to match the pseudocode in the ARM reference manual.
Corresponds to the equivalent pseudocode within the ARMv8 reference
manual. This will be necessary for supporting half-precision
floating-point.
This also makes use of it within FPConvert
Adds a template function that performs the same behavior as in the ARM
pseudocode, and utilizes it in FPConvert, which will be necessary for
half-float support.
The AddressRange structure isn't used anywhere within the codebase, so
this can be removed. Particularly because there's no real appeal/heavy
potential use of it in the future that isn't trivial to add back if
needed.
