On 01.10.2012 16:56, Sven Van Caekenberghe wrote:
On 01 Oct 2012, at 16:33, Henrik Sperre Johansen <[email protected]>
wrote:
On 01.10.2012 14:43, Sven Van Caekenberghe wrote:
On 01 Oct 2012, at 14:01, Henrik Sperre Johansen <[email protected]>
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
