From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA01895 for caml-redistribution; Wed, 12 Aug 1998 22:07:36 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA13586 for ; Wed, 5 Aug 1998 10:00:24 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id KAA04806; Wed, 5 Aug 1998 10:00:19 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA14903; Wed, 5 Aug 1998 10:00:19 +0200 (MET DST) Message-ID: <19980805100018.38349@pauillac.inria.fr> Date: Wed, 5 Aug 1998 10:00:18 +0200 From: Xavier Leroy To: Christopher Oliver , caml-list@inria.fr Subject: Re: Marshalling of floats References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from Christopher Oliver on Tue, Aug 04, 1998 at 02:38:55PM -0400 Sender: weis > 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