Rich Felker
Floating point puzzle time. Suppose you have two floating point numbers A and B you want to add, but with the result A+B rounded to fewer (a predetermined specific number) mantissa bits than what are available in the type you're working with.
Are there any tricks to do this, possibly using some biases, that don' t amount to just doing "full soft-float"? I don't see an obvious way.
Rich Felker
@joe That's a double-rounding - the addition already rounded once and now you're rounding again. The goal is to get the rounding of the exact result a+b, not the rounding of a rounding.
Joe Groff
@dalias if you're ok with the default rounding mode, i think you could do `result + 0x1.0pNNN - 0x1.0pNNN` to push the significand bits you don't want off the edge
Rich Felker
@steve Round-to-nearest is the interesting case. The other rounding modes make double rounding idempotent.
I Can't Believe It's Not Zero!
@dalias Do you have any control over the magnitude of A and B? Do you want round-to-nearest?
Rich Felker
@joe It's not that easy because you don't know the bias needed until you know the exponent of the result. Which potentially changes under different ways of rounding.
Joe Groff
@dalias i see. if A and B fit within single precision, you could promote to double precision and pre-bias one of the operands with 0x1pNNN so that the result gets rounded at the right point. trying to think if there's a way to get the effect without promoting to a higher-precision intermediate type…
Rich Felker
@steve This is actually part of a thought experiment for "can we make decently efficient, non-excess-precision float/double arithmetic on ld80-only archs?"
Rich Felker
@steve GCC's -fsoft-float generates calls to __add[sd]f3, etc., so if you could implement versions of those in terms of hard float but with the right rounding applied, you'd have a trivial-to-integrate solution.
I'm mainly thinking of this from a standpoint of hosting language interpreters for languages where floating point arithmetic is central, which are currently just broken entirely on 32-bit x86 and m68k. This includes lua, php, javascript, and even qemu I think.
Rich Felker
@steve I guess you can just do the addition and double-round except when the result was on an exact boundary case, and only fallback to a slow path then. The constant-time folks would hate it but it's probably very fast overall.
I Can't Believe It's Not Zero!
@dalias probably not "decently efficient" in a way that's meaningfully better than soft float. You can conditionally do SW fixup to round to odd in 80bit then round-trip to memory to get the rounding, but it's pretty meh.
Rich Felker
@joe @steve The Win32 ABI is just broken. There is no "double precision mode" on x87. The mode they call that has 53-bit mantissas but 15-bit exponents, not 11-bit ones, except that they get crunched to 11-bit on store to memory. This makes for a far worse mess to clean up, as you not only have double roundings but a new type that behaves as if rounding took place in a different type that nominally doesn't exist and that you can't really access.
Joe Groff
@dalias @steve the Win32 ABI kicks `long double` to the curb and keeps the x87 permanently in double precision mode. i don't suppose there's any appetite for a gcc ABI variant that does something similar
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.