Hi Steph,

On Sun, May 16, 2010 at 11:24 AM, St�phane Ducasse <stephane.ducasse@inria.fr> wrote:
elliot

that the format is in the image is good know. Do you know where we can find the information I imagine in VMmaker
But sometimes we want to be able to script the image itself without restarting it.

The method is Interpreter>>writeImageFileIO:. �Here's the relevant extract from the slightly extended method in Cog:

headerSize := 64. �"header size in bytes; do not change!"

f := self cCode: 'sqImageFileOpen(imageName, "wb")'.
f = nil ifTrue: "could not open the image file for writing"
[^self primitiveFail].

headerStart := self cCode: 'sqImageFileStartLocation(f,imageName,headerSize+imageBytes)'.
self cCode: '/* Note: on Unix systems one could put an exec command here, padded to 512 bytes */'.
"position file to start of header"
self sqImageFile: f Seek: headerStart.

self putLong: self imageFormatVersion toFile: f.
self putLong: headerSize toFile: f.
self putLong: imageBytes toFile: f.
self putLong: self startOfMemory toFile: f.
self putLong: specialObjectsOop toFile: f.
self putLong: self newObjectHash toFile: f.
self putLong: self ioScreenSize toFile: f.
self putLong: self getImageHeaderFlags toFile: f.
self putLong: extraVMMemory toFile: f.
self putShort: desiredNumStackPages toFile: f.
self putShort: self unknownShortOrCodeSizeInKs toFile: f.
self putLong: desiredEdenBytes toFile: f.
self putShort: (maxExtSemTabSizeSet ifTrue: [self ioGetMaxExtSemTableSize] ifFalse: [0]) toFile: f.
self putShort: 0 toFile: f.
1 to: 4 do: [:i | self putLong: 0 toFile: f]. �"fill remaining header words with zeros"

So the simple header (the header without an initial 512 bytes used on some Mac systems) looks like:

bytes �0 to �3: image version number in either little or big endian order (used to determine header and image byte order)
6504 for 32-bit images
68002 for 64-bit images
6505 for 32-bit Cog images (slightly different compact class layout)
bytes �4 to �7: header size (e.g. 64 bytes)
bytes �8 to 11: image size in bytes
bytes 12 to 15: address of start of first object in image (nil) when image was saved (*)
bytes 16 to 19: address of specialObjectsOop (not start of specialObjectsOop) when�image was saved (*)
bytes 20 to 23: next object hash (unused in Cog)
bytes 24 to 27: screen width << 16 + screen height
big endian: bytes 24 & 25 are width, little endian: bytes 24 & 25 are height
bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also uses bits 1 through 4
bit 0: 1 => open full screen, 0 => open using width & height
bit 1: 1 => image floats are in little-endian format, 0=> image floats are in big-endian format
bit 2: 1 => Process's 4th inst var (after myList) is threadId to be used by the VM for overlapped calls
bit 3: 1 => set the flag bit on methods that the VM will only interpret (because they're considered too big to JIT)
bit 4: 1 => preempting a process does not put it to the back of its run queue
bytes 32 to 35:�extra vm memory (typically 0)
bytes 36 to 37: number of stack pages to allocate
bytes 38 to 39: amount of memory for JITed code in 1024k units (63 MB max)
bytes 40 to 43: size of the eden zone
really a value that determines how much memory to allocate before doing an incremental collection
bytes 44 to 45: max size of the external semaphore table (64k max)
bytes 46 to 47: 0, reserved for future use
bytes 48 to 63: 0, reserved for future use


So e.g. if anyone writes an image modification utility please try and preserve the entirety of the header, modifying only what you need to modify, so as not to break future VMs.


HTH
Eliot

Stef
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project