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 bootstrap.

Even when doing the blueprint trick, what remains to be done is simulating  
additions to the method dictionary.

> Cheers,
>    - Andreas
>