On Wed, Jul 02, 2014 at 09:12:37AM -0500, Jeff Epler wrote: > When someone asked today about the bitness of hal_float_t, I was > reminded that as far as I know, nobody ever looked into whether the > ARM-based systems handle atomic stores to volatile doubles. > Unfortunately, the answer seems to be "no".
.. so what's the price of doing nothing-- that is, leaving hal_float_t as a typedef for volatile double in an ARM port? (The following discussion assumes that you understand the binary representation of floating-point numbers) Well, the guarantee is that when you read a 64-bit value written by some other thread of execution, if you don't get all 64 bits from a single write, you'll get 32 bits MSBs from one write and 32 bits LSBs from another write. Within a double-precision number, the "first" 32 bits (the ones that would be the MSBs in an integral type) contain the sign (1 bit), exponent (11 bits), and most significant part of the mantissa (20 bits + implied leading 1); the "second" 32 bits are 32 LSBs of the mantissa. Contrast this with the single-precision floating-point type, which has a sign bit, 8 bits of exponent, and 23 bits of mantissa (again with implied leading 1). So in this model, what's the consequence of reading a half-written value? Whichever of the old or new value you get the leading 32 bits from will be dominant, and the other value will replace the correct 32 least significant bits with some other 32 bits. This means that, in that tiny fraction of cases where you read a mixed value, you read a value that is accurate in its sign bit, its exponent, and 21 bits of its mantissa. The rest of the time, of course, you get the full 53 bits of precision. Contrast that to if we changed hal_float_t to a float: You get 24 bits of precision, all the time. So what's the better decision: usually 53 bits of precision, but occasionally (and unpredictably) 21 bits of precision? Or 24 bits of precision predictably and always? It seems like only a few systems that would work with 24-bit precision would fail with 21-bit precision, and an occasional transient error (in, say, feedback position or velocity) which occurs down at the 7th significant digit wouldn't matter much. That, coupled with the typical ARM boards being uniprocessor systems (this type of atomicity error is MUCH harder to provoke in UP systems, probably by a factor of a million or so) is probably why nobody using one of those systems has noticed a problem and diagnosed it as coming from this source. Jeff ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
