thanks On May 17, 2010, at 8:03 PM, Eliot Miranda wrote:
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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project