[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