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

David T. Lewis lewis at mail.msen.com
Sun Apr 15 18:29:45 UTC 2018


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 ;-)

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