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

Eliot Miranda eliot.miranda at gmail.com
Sun Apr 15 19:42:29 UTC 2018


Hi David,

> On Apr 15, 2018, at 11:29 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> 
> Hi Eliot,
> 
> Yes for sure it was not a great idea. But that is the way it actually
> got done, so it is documented accordingly in ImageFormat. I expect that
> it was one of those "simplest things that could possibly work" situations,
> so the header words just got written in 64 bits per word, which would
> make them large enough to handle a few of the fields that do require
> 64 bit range.
> 
> A suitably motivated person (that's not me) could update the VM in a
> backward compatible way to produce a more sensible header format, but
> the old headers should still be handled in ckformat (via ImageFormat)
> in order to identify existing image files.
> 
> By the way, it wasn't me that did this. You would have to complain to
> Dan or Ian on this one ;-)

Don't worry; I'm not holding you responsible :-)

> 
> Dave
> 
> 
>> On Sun, Apr 15, 2018 at 11:07:36AM -0700, Eliot Miranda wrote:
>> 
>> Hi David,
>> 
>>    I have to observe that storing the version number in one width for 32-bits and a wider one for 64-bits is a very bad idea:
>> - the wider version number must avoid half widths that are ambiguous
>> - tools using the narrower width (which was adequate when the narrower format was defined) are broken by the wider width
>> 
>> I think an additional fix is the have the non-Spur 64-bit vm ignore the upper bits of to store the same bits in either half.
>> 
>>> On Apr 15, 2018, at 7:51 AM, commits at source.squeak.org wrote:
>>> 
>>> 
>>> David T. Lewis uploaded a new version of ImageFormat to project VM Maker:
>>> http://source.squeak.org/VMMaker/ImageFormat-dtl.31.mcz
>>> 
>>> ==================== Summary ====================
>>> 
>>> Name: ImageFormat-dtl.31
>>> Author: dtl
>>> Time: 15 April 2018, 11:51:24.795 am
>>> UUID: 0d9cd87d-1743-4962-b490-7da14c1d0366
>>> Ancestors: ImageFormat-dtl.30
>>> 
>>> Fix ckformat for 64 bit Spur, which saves format number in first 4 bytes of the header, versus 8 bytes for 64 bit V3. Prior version worked by accident for little endian host using strncmp() check, but failed when correct memcmp() was used without limiting check to 4 bytes for spur and 8 for V3.
>>> 
>>> =============== Diff against ImageFormat-dtl.30 ===============
>>> 
>>> Item was changed:
>>> ----- Method: ImageFormat class>>versionNumberByteArrays (in category 'utility') -----
>>> versionNumberByteArrays
>>>     "All byte array expressions of known version numbers. These are the possible values
>>> +    that may appear in the first 4 or 8 bytes of a saved image file. All 32 bit images have
>>> +    this number in the first 4 bytes of the image file header. A 64 bit V3 image has this
>>> +    number saved in the first 8 bytes of the header (only 4 bytes of which are significant).
>>> +    For a 64 bit Spur image, the number is saved in the first 4 bytes. In all cases, the value
>>> +    may be stored in little endian or big endian byte ordering depending on the host
>>> +    platform (although all currently supported VMs are for little endian host platforms)."
>>> -    that may appear in the first 4 or 8 bytes of a saved image file. A 64 bit image saves
>>> -    its image format number as a 64 bit value in the file header, and a 32 bit image saves
>>> -    its image format as a 32 bit value. The value may be stored in little endian or big endian
>>> -    byte ordering depending on the host platform."
>>> 
>>>     "ImageFormat versionNumberByteArrays do: [:e |
>>>         Transcript cr; show: e printString , ': ', (ImageFormat fromBytes: e) description]"
>>> 
>>>     ^self allVersionNumberByteArrays select: [:e |
>>> +        e size = 4
>>> +            or: [ (self fromBytes: e) requiresSpurSupport not ]].
>>> -        e size = (self fromBytes: e) wordSize]
>>> !
>>> 


More information about the Vm-dev mailing list