[MUD-Dev] Re: [CODE QUESTION] How to encode floats into bytes?

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

Travis S. Casey wrote:
> On Wed, 9 Sep 1998, Ola Fosheim Gr=F8stad wrote:
> > Depending on the compiler the following should fix errors introduced =
by
> > optimization?
> >
> >   volatile float f =3D 42.5f;
>=20
> If I understand the "volatile" keyword correctly, it tells the compiler
> that other programs may be able to change the data object in question, =
and
> therefore, the program should not try to optimize out references to the
> variable.

[...]

> However, it *doesn't* tell the compiler not to optimize uses of the
> variable in other ways... hence, a "fast math" library might still
> introduce rounding errors or other errors... it just would actually acc=
ess
> the variable every time its value was requested.
>=20
> Again, this is if my understanding of "volatile" is correct.

Hmm... I guess you are right, but volatile doesn't strictly *tell* the
compiler anything, it is a hint suggesting that optimization may not be s=
uch
a great idea. (so I should have written "could" and not "should").

Quoting K&R "The C programming language" (2nd ed) p 211:

  "There are no implementation-independent semantics for volatile objects=
."

  "The purpose of volatile is to force an implementation to suppress
   optimization that could otherwise occur.  For example, for a machine
   with memory-mapped input/output [...] a compiler may ignore these
   qualifiers"

"C++ ARM" (1992) is specific about aggressive optimization and concurrent
changes though, but it is still a hint. Dunno about the ANSI spec. Given
that compilers can be somewhat sloppy about standards you basically have =
to
know your compiler anyway :-(( An obvious alternative would be to throw
the conversion code in a separate object file (Depending on whether the
fast-math option requires a global recompilation, which would make the
option less useful.)

And I don't think the implied trouble was rounding errors, but whether &f
points to a valid IEEE float or not? "Buggy" optimization is generally a
compiler issue and not a language issue, but volatile or separate
nonoptimized compilation could be worth testing out if one runs into this
kind of trouble (my experience).  When it comes to optimization we
unfortunatly place our sanity in the hands of the allmighty Compiler Imps
and their knowledge of the art of program verification (or lack thereof).
(Did anyone mention g++?).
--
Ola Fosheim Groestad,Norway