[Vm-dev] VM Maker: ImageFormat-dtl.49.mcz

David T. Lewis lewis at mail.msen.com
Sun Jan 10 16:11:30 UTC 2021


On Sun, Jan 10, 2021 at 11:30:50AM +0530, K K Subbu wrote:
> 
> On 10/01/21 5:39 am, commits at source.squeak.org wrote:
> >+ ----- Method: CogImageFileHeader>>readFieldsFrom:littleEndian:into: (in 
> >category 'reading') -----
> >+ readFieldsFrom: aStream littleEndian: littleEndian into: aCollection
> 
> Passing endian flag to every read looks like an overkill, doesn't it?
> 
> >+ 			[ 16r00001966 "6502" ] -> [ imageFormat := 
> >ImageFormat fromInteger: 6502. littleEndian := false ] .
> 
> The endianness is fixed when the imageFormat is instantiated. If it 
> could be encapsulated as part of this instance, then there is no need to 
> pass it as an argument for every read from the store associated with 
> this image instance.
> 
> Ideally, the image store type (little/big endian) should be separated 
> from the image encoding format (32-bit, 64-bit, ....). But I guess this 
> separation can evolve over time.
> 
> Regards .. Subbu

Hi Subbu,

It is an interesting question and I'm glad you spotted it. In the VM,
the logic for reading and writing the snapshot header is buried in the
code where most people will never see or think about it. So I am trying
to make it more accessible.

Although I have reorganized it a bit, the code that you are quoting
is patterned after the actual image loading methods in VMMaker. When
loading an image file, the very first thing that happens is that the
first few bytes of the file are read and decoded. The method that does
this figures out the endianness as a side effect of decoding the image
format number, so it is a function with two side effects. At this point
it knows the endianness of the data stored in the image file, which
will be the endianness of whatever machine actually saved the file,
not the endianness of the machine that is currently loading the file.

This endianness information is needed only for the remainder of the
image loading process. Once the image is loaded into memory, and
before the VM begins actually running that image, the endianness
flag is no longer required and can be discarded.

The reason for this complication is that we want an image file that
was saved by a big endian machine to be loadable on a little endian
machine and vice versa. We also want this to be fast and efficient,
so the policy is to always write an image file in the natural endianness
of the machine that is running it, and do extra byte swapping if and
only if the image file is being loaded by a different kind of computer.

This was a design decision that was made many years ago, and it
still works well today. But computers are a lot faster today, and
it might be perfectly legitimate to adopt a policy of always saving
an image file in e.g. network byte order. With today's fast computers,
it is possible that you would never notice any performance impact.
I have never tried it, but this might be an interesting experiment
for a student to try.

Dave


More information about the Vm-dev mailing list