Hi David,

On Sun, Jul 26, 2020 at 07:27:23PM +0200, stes at PANDORA.BE wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> 
> Sorry for asking, but from your posting it is not so clear (to me at least),
> what V3 format is.

Good question, and to be honest I actually don't know where the term "V3"
originates, but within VMMaker it refers to the traditional object memory
format prior to the introduction of Spur.


> 
> I wonder whether this has anything to do with for example the 68000 format:
> 
> bash-4.4$ ckformat sq64-20101106-dtl.image
> 68000
> 
> There was a 68000 format for 64-bit Squeak V4 images, if I understand rightly.
> 

There is a very good (brief) description of the object memory format in
class ObjectMemory, written by Dan Ingalls. It describes the original
32-bit object memory, as well as the simple 64-bit extension of that format
that Dan did with Ian Piumarta. This was (I believe) intended as TSTTCPW
to prove out the viability of 64-bit images. Later work by Eliot Miranda
gave us the 64-bit (and 32-bit) Spur object memory that is used for
Squeak images today.

The original object memory (both 32-bit and 64-bit) was designed at a
time when 64-bit computers and cell phones were in the distant future.
Spur is a newer design that takes better advantage of today's 64-bit
machines, and that also eliminates some design limitations going back
to those earlier days. For example, Spur uses a common object header
design for 32- and 64-bit images, and it permits more kinds of objects
(characters, floating point objects) to be efficiently represented 
internally as immediate objects.

Note, there is no such thing as a "V4 image", we had some releases of
Squeak in the "version 4.x" range. But it is just an accident of naming
conventions that the last of the "V3" image formats ended with the
Squeak 4.6 release. Squeak 5.x is based on Spur, and Squeak 4.6 and
earlier used the V3 image format.


> It would be nice if the "ckformat" C program would print the same info as:
> 
> ImageFormat versionDescriptions
> 
> a Dictionary(6502->'a 32-bit image with no closure support and no native platform float word order requirement (6502)' 6504->'a 32-bit image with closure support and no native platform float word order requirement (6504)' 6505->'a 32-bit image with closure support and float words stored in native platform order (6505)' 6521->'a 32-bit image with closure support and float words stored in native platform order using Spur object format (6521)' 68000->'a 64-bit image with no closure support and no native platform float word order requirement (68000)' 68002->'a 64-bit image with closure support and no native platform float word order requirement (68002)' 68003->'a 64-bit image with closure support and float words stored in native platform order (68003)' 68019->'a 64-bit image with closure support and float words stored in native platform order using Spur object format (68019)' )
> 
> First of all in the above there is no mention of "V3 images".
> 
> It just states images with or without closure support/float etc. 
> 
> The terminology "V3 images" is not used in the ImageFormat class.
> 
> But next, based on the Dictionary, the ckformat.c program could print
> 
> bach-4.4$ ckformat
> 6502	a 32-bit image with no closure support and no native platform float word order requirement (6502)
> 6504	a 32-bit image with closure support and no native platform float word order requirement (6504)
> 6505	a 32-bit image with closure support and float words stored in native platform order (6505)
> 6521	a 32-bit image with closure support and float words stored in native platform order using Spur object format (6521)
> 68000	a 64-bit image with no closure support and no native platform float word order requirement (68000)
> 68002	a 64-bit image with closure support and no native platform float word order requirement (68002)
> 68003	a 64-bit image with closure support and float words stored in native platform order (68003)
> 68019	a 64-bit image with closure support and float words stored in native platform order using Spur object format (68019)
> 
> and so on (for example if ckformat is used with --list or without argument).
> 
> Like this you have on the UNIX command line with ckformat the same info
> as 'ImageFormat versionDescriptions' provides.


That is a very good idea. I just updated ImageFormat-dtl.42 with your suggestion.
When called with no argument, the ckformat program now does this:

$ ./ckformat
usage: ckformat imageFileName
answer the image format number for an image file or 0 if not known
known image formats:
6502: a 32-bit V3 image with no closure support and no native platform float word order requirement
6504: a 32-bit V3 image with closure support and no native platform float word order requirement
6505: a 32-bit V3 image with closure support and float words stored in native platform order
6521: a 32-bit Spur image with closure support and float words stored in native platform order using Spur object format
7033: a 32-bit Spur image with closure support and float words stored in native platform order using Spur object format and multiple bytecode sets 
68000: a 64-bit V3 image with no closure support and no native platform float word order requirement
68002: a 64-bit V3 image with closure support and no native platform float word order requirement
68003: a 64-bit V3 image with closure support and float words stored in native platform order
68004: a 64-bit V3 image with closure support and no native platform float word order requirement
68019: a 64-bit Spur image with closure support and float words stored in native platform order using Spur object format (obsolete)
68021: a 64-bit Spur image with closure support and float words stored in native platform order using Spur object format
68533: a 64-bit Spur image with closure support and float words stored in native platform order using Spur object format and multiple bytecode sets 

I did not attempt to add argument parsing (--list) but I hope that adding
this to the zero-argument message will be good enough. It's certainly a nice
and easy enhancement :-)

Thanks,
Dave