<br><br><div class="gmail_quote">On Tue, Jul 8, 2008 at 12:08 AM, Klaus D. Witzel <<a href="mailto:klaus.witzel@cobss.com">klaus.witzel@cobss.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">On Tue, 08 Jul 2008 07:19:45 +0200, Andreas Raab wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Craig Latta wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> ...do the bootstrap: Instantiate the first process, its first context,<br>
> the first message. Run it in the simulator to set up the remaining<br>
> parts of the kernel image (Delay, ProcessorScheduler etc).<br>
I guess I found that last sentence easier said than done. :)<br>
</blockquote>
<br>
It doesn't strike me as particularly difficiult but then I haven't tried it yet. What problems were you running into?<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.)<br>
</blockquote>
<br>
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<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<div class="Ih2E3d">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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 bootstrap.<br>
</blockquote>
<br></div>
Even when doing the blueprint trick, what remains to be done is simulating additions to the method dictionary.</blockquote><div><br>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.<br>
<br>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?<br>
<br><br></div></div>