[squeak-dev] Re: Creating an image from first principles
eliot.miranda at gmail.com
Tue Jul 8 17:37:30 UTC 2008
On Tue, Jul 8, 2008 at 12:08 AM, Klaus D. Witzel <klaus.witzel at cobss.com>
> On Tue, 08 Jul 2008 07:19:45 +0200, Andreas Raab wrote:
> Craig Latta wrote:
>>> > ...do the bootstrap: Instantiate the first process, its first context,
>>> > the first message. Run it in the simulator to set up the remaining
>>> > parts of the kernel image (Delay, ProcessorScheduler etc).
>>> I guess I found that last sentence easier said than done. :)
>> It doesn't strike me as particularly difficiult but then I haven't tried
>> it yet. What problems were you running into?
>> I don't even think the global lookup issue is all that hard. (I
>>> advocate having no system dictionary; keep each class literal in the name
>>> slot of the class itself, and have a means of traversing the class tree from
>>> a well-known starting point. Scanning through memory for the class and pool
>>> literals you want is straightforward.)
>> Actually, true *globals* (which for the bootstrap means only classes) are
>> trivial to deal with: Since the skeleton is created first you have the oops
>> for all the globals right there and then, so setting up a mapping that the
>> compiler uses for these globals is utterly trivial. It's class and pool
>> variables that are tricky
> I suggest that vars are the same as in the "blueprint" classes (thank you
> Michael for mentioning that term elsewhere :) so, the methods can be
> compiled against ordinary classes which serve as blueprint.
> And globals can be in a single Sharedpool for the time of creating the
> image from first principles (see my patch to SharedPool>>#bindingOf:).
> Having said that, globals could alternately be treated as if they where
> class variables of Object blueprint. Both variants can avoid having a
> Smalltalk global dictionary.
> because even Dictionary>>at: may not exist in the image that you're trying
>> to compile so doing the lookup directly in there would be quite tricky. It
>> would be doable if one assumed a particular organization of the classes
>> (i.e., the n-th iVar is the dictionary of class vars) and then interpreted
>> it externally but it seems like an unnecessary complication for an initial
> Even when doing the blueprint trick, what remains to be done is simulating
> additions to the method dictionary.
In the image (not in the simulator) create proxy objects for the selectors
in the simulator heap that answer the identity hashs of the objects in the
simulator hash. Create a method dictionary in the image populated with the
proxy objects. The order of the objects in the image method dictionary is
the correct order for the method dictionary in the simulator.
In general if you want to perform a computation on objects in the simulator
heap before you've bootstrapped the code to perform the computation, create
proxy objects in the image and run the computation on them. Right?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev