At 12:14 AM +0200 12/14/09, Igor Stasenko apparently wrote:
>Hello guys,
>
>please take a look at changeset i just uploaded:
>
>http://bugs.squeak.org/view.php?id=7428
>
>There is an initial implementation of CompiledMethodTrailer with some
>test coverage.
>
>My motivation behind this is simple:
>
>1. no more poking with raw bytes, like this:
>
>holdsTempNames
>	"Are tempNames stored in trailer bytes"
>
>	| flagByte |
>	flagByte := self last.
>	(flagByte = 0 or: [flagByte = 251 "some source-less methods have flag
>= 251, rest = 0"
>			and: [(1 to: 3) allSatisfy: [:i | (self at: self size - i) = 0]]])
>		ifTrue: [^ false].  "No source pointer & no temp names"
>	flagByte < 252 ifTrue: [^ true].  "temp names compressed"
>	^ false	"Source pointer"
>
>or this:
>
>endPC
>	"Answer the index of the last bytecode."
>	| size flagByte |
>	"Can't create a zero-sized CompiledMethod so no need to use last for
>the errorEmptyCollection check.
>	 We can reuse size."
>	size := self size.
>	flagByte := self at: size.
>	flagByte = 0 ifTrue:
>		["If last byte = 0, may be either 0, 0, 0, 0 or just 0"
>		1 to: 4 do: [:i | (self at: size - i) = 0 ifFalse: [^size - i]]].
>	flagByte < 252 ifTrue:
>		["Magic sources (temp names encoded in last few bytes)"
>		^flagByte <= 127
>			ifTrue: [size - flagByte - 1]
>			ifFalse: [size - (flagByte - 128 * 128) - (self at: size - 1) - 2]].
>	"Normal 4-byte source pointer"
>	^size - 4
>
>2. method's trailer can be used for storing a variety of stuff, not
>just source pointer or temps names. And it will be easy to add new
>kinds of trailers.
>    A most useful, as to me, and which i've added initially is:
>  - being able to embed the source code in trailer, so a compiled
>method and its source lives together in image.
>     Some of you have expressed this idea before, so here it is.
>  - being able to retrieve the method's source using other way, than
>through SourceFiles or embedded in trailer.
>     I added two kinds of trailers for that:
>     - get method's source by class+selector where it installed to.
>     - get method's source by class+some string identifier
>
>  - yours. Please tell me, what kind you want to have in addition.
>
>3.  a source pointer could surpass the 32Mb limit. A CompiledMethod
>already can encode a source pointer value of any size.
>  Its now only a matter of fixing the source pointer encoding logic to
>enable having .source and .changes files above 32Mb.
>
>Please, review my code and send me your comments and wishes.
>At next stage i will create a changeset which will put this stuff in
>use, as well as cleanup lots of places in CompiledMethod and
>compiler/decompiler.
>
>--
>Best regards,
>Igor Stasenko AKA sig.

Not sure how this relates exactly but there has been quite a bit of work in the past re: Virtual Image 4.0 format.
See:
New Compiled Method Format
<http://wiki.squeak.org/squeak/750>

and:
VI4 project
<http://wiki.squeak.org/squeak/2119>

Here is an old related message from Tim Rowledge on Oct 20, 2005:
At 1:23 PM -0700 10/20/05, tim Rowledge apparently wrote:
>Delivered-To: list-squeak-dev at lists.squeakfoundation.org
>From: tim Rowledge <tim at rowledge.org>
>Date: Thu, 20 Oct 2005 13:23:20 -0700
>To: The general-purpose Squeak developers list
>	<squeak-dev at lists.squeakfoundation.org>
>Subject: Re: new image format (was: Actually doing something!)
><>
>
>On 20-Oct-05, at 1:01 PM, Jecel Assumpcao Jr wrote:
>
>>Tim Rowledge wrote on Wed, 19 Oct 2005 15:41:31 -0700
>>
>>>Squeak is about 10 years old. Time to move from toddler to pre-
>>>schooler at least. Yes, it will mean a break in being able to run old
>>>images on new VMs. So what; old VMs will still be there. The
>>>sourcecode is still on SVN.
>>>
>>
>>I guess this is a good time to ask about Anthony Hannan's "image version
>>4 format" work (http://minnow.cc.gatech.edu/squeak/VI4). Bryce Kampjes
>>mentioned incompatibilities as the reason why this is no longer being
>>considered for inclusion in Squeak, but reading all the documentation
>>and scanning quickly through the sources the only thing I noticed was
>>that the needed debugger changes were not finished. Am I missing
>>something?
>
>I don't know. Some of his work got included anyway (some prims to support closures and I think
>continuations) other stuff is superseded and probably a lot is suffering from bitrot since I don't recall hearing from him in ages. Are you there AJH?
>
>I'd like to see the closures being properly supported and made standard, whether through his code or other code. It really is a bit bad to still be without them. The page http://minnow.cc.gatech.edu/squeak/3717 is terribly out of date as well and Dan seems to have drifted off of this path. http://minnow.cc.gatech.edu/squeak/3718 is at least a year behind the times.
>
>
>tim
>--
>tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim

Ken G. Brown