> First, floats are simply written in increasing byte order OCAML
> makes no attempt to rearrange based on endianness.

Floats are written in "native" endianness (the natural endianness of
the machine writing the file), but along with a flag telling which
endianness is used.  input_value, then, swaps bytes if it runs on a
processor whose endianness does not match that used to create the
file.  This is more efficient than converting to and from a fixed
endianness in the frequent case where the data is read back on the
same machine that wrote it.

> Should OCAML swap byte orders on some hardware to try to compen-
> sate, or should we make no attempt to record floating point
> portably between the major architectures?  The change in byterun/
> intern.c and byterun/extern.c to handle byte swapping is fairly
> trivial provided we include the config.h

input_value/output_value is already portable across all platforms that
use IEEE floats.  The byte-swapping code is already in byterun/intern.c.

> Harder, does anyone have any good ideas besides conversion to
> and from lists for marshalling floating arrays between bytecode
> and native OCAML programs?  Without this sort of thing, one must
> walk structures by hand if there are variant types with floating
> arrays.

The next release of OCaml will use the same format for float arrays in
native-code and in bytecode, thus solving this problem.

Regards,

- Xavier Leroy