On Wed, Jul 23, 2008 at 10:57 AM, Klaus D. Witzel <klaus.witzel at cobss.com>
wrote:

> 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?


No VMs are available.  Right now you have to roll your own.  I don't have
the time or expertise to provide an adequate sampling of VMs.  I don't even
have a clear picture of what different VMs are out there.  Note that Qwaq's
VM contains properietary code, so I cant simply make that available.  So
take your own VMMaker package or download one, apply the changeset and spit
out your own.  I guess we could try to get it tother to produce a 3.9 VM for
the three x86 platforms, Mac OS X, Win32 & Intel Linux.  But I'm not going
to do this anytime soon.  I'm not an expert in building and configuring
Squeak VMs for general consumption.  I'd rather leave that to the likes of
Tim, John, Andreas and Ian.  Noblese oblige ;)


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.
>>>>
>>>>
>>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080723/9fe9137f/attachment.htm