On 01.10.2012 16:56, Sven Van Caekenberghe wrote:
On 01 Oct 2012, at 16:33, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
On 01.10.2012 14:43, Sven Van Caekenberghe wrote:
On 01 Oct 2012, at 14:01, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
Endianness in header depends on the platform the image was saved on. Which for all practical purposes, means little-endian these days. How can an image be cross-platform, but the header not ?
IIRC, because the VM checks which endianness the header is written in (by comparing to known image formats in big and little-endian format), and then triggering a swap of all pointers/variableWord objects when loading the image on a differing platform. Thanks for the answer, I suspected something like that.
But that means that the image format on disk, being binary, is native only to one endianess and not the other, Yes making startup or saving a image faster/slower depending on whether the conversion needs to be done, right ? Or is this automagically fixed with the first save ?
Swapping happens at startup, so penalty is only when loading a big-endian image on little-endian platform or vice versa. Without saving, that happens every time, it is not automatically saved if a conversion takes place when loading. When saving, it saves in the platform endianness (which is the same as is in memory), and incur no extra penalty. Incidentally, that's the same approach I suggested Mariano use in fuel. IMHO, it really is most optimal approach when platform endianness changes are rare, and the penalty can easily be avoided by simply saving the image on the platform it is intended to be used. Cheers, Henry