On Wed, 23 Jul 2008 17:14:38 +0200, Eliot Miranda wrote:

> On Wed, Jul 23, 2008 at 6:34 AM, Klaus D. Witzel wrote:
...
>> ... example, what 3.9 plus VMMaker did you use (patches?). Can I
>> prepare an .image by myself or do you intend to upload a prepared one?
>
> I didn't use a VMMaker in 3.9.  I simply used the modified Qwaq VM to run
> all bootstraps.

Hm, then my question should have been: is this modified VM available for  
the win32's?

> But I did run the bootstrap in Qwaq internal images,
> Croquet 1.0.18 and Squeak3.9-final-7067.
>
> I think at this stage the code is too green for me to upload a prepared
> image.  I'd rather people built their own.  That way I can still fix and
> change details before things get too frozen.

Okay. I was reflecting mainly the VM source code changes here. I'll skip  
them.

> One example is whether to use indexed inst vars to hold copied values in
> BlockClosure, or as I do currently to use an Array.  If using an inst var
> closure creation is slower but adding inst vars is easy.

Since there where 1-2 questions during recent years, for adding instVars  
to some subclass of ContextPart, why not?

> If using indexed
> inst vars then either the VM makes it impossible to add inst vars  
> (something
> up with which I shall not put) or the code for evaluation is slowed down
> because the VM needs to find the size of the closure and the number of  
> named
> slots.  So there needs to be a performance evaluation done of each  
> approach.

Performance of loading the array oop from its slot v.s. computing # of  
named slots? How about just incrementing stackPointer for allocating the  
closure's slots (as is done for method temps) when the BlockClosure is  
created. Of course this then needs a base value (like initial IP has).

> Another example is temp names for the debugger and for sourceless  
> methods.
>  I'm not sure I've got the former right and I broke the latter.  I  
> suspect
> that there is a middle ground that solves both of these.

This was also a problem for the current Decompiler (IIRC Stef posted such  
an example long time ago).

> So for now build your own images and contact me with comments,  
> suggestions
> fixes etc, either directly or to the blog.

Will see what is possible by using 3.8 as base (most likely not before  
Saturday).

> Eventually I'll have to grok
> some form of issue tracking (and suggestions are welcome) but for now  
> I'll keep it cheap and cheerful.
>
>>
>> /Klaus
>>
>>  and tying up loose ends (for example I broke decompile with temp names  
>> and
>>> haven't fixed it).
>>>
>>> Thanks and enjoy.
>>>
>>