[squeak-dev] Re: new blog post plus closure bootstrap code
Klaus D. Witzel
klaus.witzel at cobss.com
Wed Jul 23 17:57:57 UTC 2008
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.
>>>
>>
More information about the Squeak-dev
mailing list
|