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

K K Subbu kksubbu.ml at gmail.com
Mon Jan 11 07:35:52 UTC 2021

On 10/01/21 9:41 pm, David T. Lewis wrote:
> 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 dumping of object graph into image file worked well as long there 
were only one or two formats. But now there are so many image variants 
that stream reader/writers like in GIF or PNG would be simpler and 
cleaner (ImageReader/ImageWriter?). It would also allow new VMs to 
"import" all old formats.

You're right about byte-swap cost not being significant on modern 
machines. If htonx/ntohx works for network i/o it should work better for 
storage I/O. Perhaps, the next iteration of image format could settle on 
network byte order and eliminate endian image variants.

> 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 VM works with only one image at a time, so the cost of one property 
in ImageReader singleton will be small compared to simplification of 
messages. The property will also be reclaimed when the stream is closed.

Regards .. Subbu

More information about the Vm-dev mailing list