OK, thanks guys, I learrned new things today. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
On 01 Oct 2012, at 17:08, Henrik Sperre Johansen <[email protected]> wrote: > 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 > >
