Now I have a 4.0 vm & image working nicely on my RISC OS Pi I need to move forward to more modern images and VMs. I find myslef a touch confused about what image format changes might have happened and when.
On my iMac it seems that I can run - OK 3.9 image on 3.8 vm OK 3.9 image on 4.2 vm NO 3.9 image on Cog NO 4.1 image on 3.8 vm OK 4.1 image on 4.2 vm ?? 4.1 image on cog (crashed after mostly starting up) NO 4.3 image on 3.8 vm OK 4.3 image on 4.2 vm OK 4.3 image on cog OK scratch image (2.8 image, I think) on 3.8 vm OK scratch image on 4.2 vm NO scratch image on cog Couldn't spot anything very noticeable on the sites I scanned. Pointer to history of these changes? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim "#define QUESTION ((bb) || !(bb)) - Shakespeare." |
On Mon, Feb 11, 2013 at 03:27:59PM -0800, tim Rowledge wrote:
> Now I have a 4.0 vm & image working nicely on my RISC OS Pi I need to move forward to more modern images and VMs. I find myslef a touch confused about what image format changes might have happened and when. > > On my iMac it seems that I can run - > OK 3.9 image on 3.8 vm > OK 3.9 image on 4.2 vm > NO 3.9 image on Cog > NO 4.1 image on 3.8 vm > OK 4.1 image on 4.2 vm > ?? 4.1 image on cog (crashed after mostly starting up) > NO 4.3 image on 3.8 vm > OK 4.3 image on 4.2 vm > OK 4.3 image on cog > OK scratch image (2.8 image, I think) on 3.8 vm > OK scratch image on 4.2 vm > NO scratch image on cog > > Couldn't spot anything very noticeable on the sites I scanned. Pointer to history of these changes? > Hi Tim, Before you go any further, load package ImageFormat from the VMMaker repository at http://www.squeaksource.com/VMMaker. Everything I know about the image format changes is there. It's a stand alone package, no dependencies on VMMaker itself, so just load it and browse. The most important change is due to Eliot's block closure implementation, which was the transition from image format 6502 to 6504. An additional change came with 6505, which is 6504 plus floats (C doubles) in native word order, plus some Cog-related additional information in the image file header. An interpreter VM can load and run any of these image formats. A Cog VM requires 6504 or 6505. An image saved from an interpreter VM will be in format 6504, and an image saved from Cog will be in format 6505. Image formats 68000 and 68002 are 64-bit versions of 6502 and 6504 respectively, and require an interpreter VM compiled with the --image64 option passed to Ian's CMake configure. Format 68003 is hypothetical, reserved for Cog running the current 64-bit image. Evaluate "ImageFormat createCkFormatProgram" and compile the resulting ckformat.c to get a utility program for checking the image format number of foo.image. Dave |
OK, that all makes some sort of sense.
It would be good to document that somewhere but I'm not sure where would be best. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful Latin Phrases:- Mellita, domi adsum. = Honey, I'm home. |
While David's great explanation about image version numbers perfectly
answers Tim's question given that he is interested in relatively recent images (3.9 and newer), I'll add one comment about older stuff for historical completeness. Eliot has used the version numbers exactly as they were meant to be used, but previous VM developers were a little more sloppy. The unofficial policy during the Squeak Central years was that images and VMs should be compatible at least two versions apart. So a 2.4 VM should be able to at least work perfectly with 2.2, 2.3, 2.4, 2.5 and 2.6 images. The idea is that nobody would care about anything more than that, so subtle changes were allowed while keeping the image version numbers always at 6502. I am aware of one case of broken backwards compatibility, but have the impression that there were at least 3 and perhaps more. At some point an image would change such that some primitive was no longer needed. It would be left in the VM anyway due to the policy I mentioned above. Several versions later, some new primitive would be needed for a new feature in the image. The old primitive number would then be reused. Or else it would be some field in a system object that would suffer this fate. In any case, there would be no problems for sufficiently close versions of VMs and images. And for distant versions it would often seem that everything was working ok since this tended to happen to rather obscure features. But eventually this combination would crash. The problem I mentioned above normally affected only those wanting to use the Simulator. Other users probably never ran into them, which is probably why this was considered an acceptable way of doing things. -- Jecel |
In reply to this post by timrowledge
thanks, i know the image format has been changed to another one but i can never figure out when the image format has been changed. so is it possible for me to stop this from happening and get the same image format.
|
Free forum by Nabble | Edit this page |