[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