Smalltalk › Squeak › Squeak - Dev

Squeak 4.6 -- 2nd release candidate

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

24 messages Options

Tobias Pape

Re: Squeak 4.6 -- 2nd release candidate

Hi Eliot

On 07.07.2015, at 23:07, Eliot Miranda <[hidden email]> wrote:

> Hi Tobias,
>
> On Tue, Jul 7, 2015 at 8:31 AM, Tobias Pape <[hidden email]> wrote:
>
> On 07.07.2015, at 17:26, Chris Muller <[hidden email]> wrote:
>
> >>> Interpreter VM will not be able to run Spur images going forward.
> >>
> >> Pardon?
> >
> > Download latest Spur image and changes:
> >
> > http://www.mirandabanda.org/files/Cog/VM/SpurImages/trunk46-spur.image
> >
> > http://www.mirandabanda.org/files/Cog/VM/SpurImages/trunk46-spur.changes
> >
> > and latest interpreter VM. Then try:
> >
> > squeak trunk46-spur.image
> >
> > Results:
> >
> > This interpreter (vers. 0) cannot read image file (vers. 6521).
> > Press CR to quit...
>
>
> Well, your sentence sounded as if there's no intention of making the interpreter
> VM SPUR-aware whatsoever. Surely I got that wrong, didn't I?
>
> I certainly hope so! I ant the Interpreter VM to be able to use the Spur memory manager. But that will realy force a merge of VMMaker and VMMaker.oscog and right now I don't see we have a lot of resource. Volunteers are /very/ welcome!
>

Thanks for pointing that out :)
I was a bit confused and I'm glad we have a nice plan :)
Best regards
-Tobias

Tobias Pape

Re: VM terminology (was: [squeak-dev] Squeak 4.6 -- 2nd release candidate)

In reply to this post by David T. Lewis

Hi Dave
On 08.07.2015, at 02:25, David T. Lewis <[hidden email]> wrote:

> On Tue, Jul 07, 2015 at 05:31:38PM +0200, Tobias Pape wrote:
>>
>> On 07.07.2015, at 17:26, Chris Muller <[hidden email]> wrote:
>>
>>>>> Interpreter VM will not be able to run Spur images going forward.
>>>>
>>>> Pardon?
>>>
>>> Download latest Spur image and changes:
>>>
>>> http://www.mirandabanda.org/files/Cog/VM/SpurImages/trunk46-spur.image
>>>
>>> http://www.mirandabanda.org/files/Cog/VM/SpurImages/trunk46-spur.changes
>>>
>>> and latest interpreter VM. Then try:
>>>
>>> squeak trunk46-spur.image
>>>
>>> Results:
>>>
>>> This interpreter (vers. 0) cannot read image file (vers. 6521).
>>> Press CR to quit...
>>
>>
>> Well, your sentence sounded as if there's no intention of making the interpreter
>> VM SPUR-aware whatsoever. Surely I got that wrong, didn't I?
>>
>
> We are probably tripping over some terminology issues here.
>
> We used to refer to the "standard VM" as distinct from the "experimental"
> Cog VMs. That terminology is no longer appropriate, because most people
> now use Cog (and Spur), and IMHO the terms "standard" and "experimentalt"
> are no longer helpful.
>
> When Eliot and Andreas began the work that led to Cog (and now Spur), the
> first step (see Eliot's blog) was development of the stack-oriented interpreter,
> which was an improvement over the original context-based interpreter of the
> standard Squeak VM. The idea was (and still is) that the standard interpreter
> VMs would migrate to the stack interpreter model.
>
> If you look at the VMMaker package (as opposed to VMMaker.oscog) you will
> find additional refactoring of the interpreter and object memory classes to
> support that original design intent. The VMs that we now call "interpreter
> VM" are generated from that code base, currently building from the context
> interpreter classes rather than the stack interpreter classes.
>
> There is some work remaining to be done in order to be able to generate
> an "interpreter VM" from the stack interpreter classes in the VMMaker
> package. Once that is accomplished, the context interpreter will become
> a historical artifact, and the "interpreter VM" builds will in fact deliver
> the stack based interpreter VM as developed by Eliot and maintained in
> the VMMaker.oscog branch.
>
> Beyond that, my powers of prediction are less clear. There is significant
> code merge work remaining to be done, but regardless of how (or when or
> by whom) that gets done, there is no reason that the new Spur object model
> should not be adopted, and no reason why an "interpreter VM" should not
> be able to support it.

Thanks for the quite enlightening explanation. :)
Together with Eliot's reply this makes going on a lot more predictable for
me. Thanks!

Best regards
-Tobias

Levente Uzonyi-2

Re: Squeak 4.6 -- 2nd release candidate

In reply to this post by David T. Lewis

There's one difference between the two versions. Using
Compiler-eem.300, the following methods are compiled with small frame
instead of large frame:

BitBltDisplayScanner>>#displayLines:in:clippedBy:
GradientFillStyle>>#computePixelRampOfSize:
InterpolatedGradientFillStyle>>#computePixelRampOfSize:
NewParagraph>>#clickAt:for:controller:
PackageInfo>>#changeRecordsForMethod:do:
PaintBoxMorph>>#addBrushesOffImage:
PaintBoxMorph>>#addShapeButtonsOffImage:onImage:
PaintBoxMorph>>#addToolsOffImage:onImage:
Paragraph>>#clickAt:for:controller:
PianoRollScoreMorph>>#addNotes
PolygonMorph>>#lineSegmentsDo:
PostscriptCharacterScanner>>#displayLine:offset:leftInRun:
SmalltalkImage>>#appendChangesTo:
StrikeFontSet>>#characters:in:displayAt:clippedBy:rule:fillColor:kernDelta:on:
SuperSwikiServer>>#fastParseEntriesFrom:
TTFontReader>>#processGlyphDataTable:offsets:
TextStyle class>>#fontMenuForStyle:target:selector:highlight:
Unicode class>>#parseCompositionMappingFrom:

Levente

On Tue, 7 Jul 2015, David T. Lewis wrote:

> On Tue, Jul 07, 2015 at 05:20:52PM -0700, Eliot Miranda wrote:
>> Hi David,
>>
>> On Tue, Jul 7, 2015 at 4:33 PM, David T. Lewis <[hidden email]> wrote:
>>>
>>> The problem was introduced in Compiler-eem.300, which does this:
>>>
>>> Use the size/emitPushNClosureTemps: api in block generation.
>>>
>>> There are two affected methods:
>>>
>>> BlockNode>>sizeCodeForEvaluatedClosureValue:
>>> BlockNode>>emitCodeForEvaluatedClosureValue:encoder:
>>>
>>> Reverting these two methods fixes the problem.
>>>
>>> I don't know the background on this change but my guess would be that
>>> it is something that works on a stack interpreter but not on a context
>>> interpreter, so maybe the methods need to be tweaked to account for the
>>> difference.
>>>
>>
>> It should make no difference to the code produced. It adds a new way of
>> saying "push N nils" that allows the Sista bytecode set to use its
>> "pushNClosureNils" bytecode to push several nils in one bytecode. But with
>> the standard encoder EncoderForV3PlusClosures exactly the same code as the
>> previous version should be produced.
>>
>> How do the changes in the compiler cause the crash?
>>
>
> I don't know.
>
> I'm doing brute-force debugging, just rolling the versions back until the
> problem goes away.
>
> All I can say with confidence is that those two methods changes, followed by
> a system recompile, result in an image that crashes a context interpreter VM.
> Reverting these two methods and recompiling brings the image back to a sane
> condition.
>
> It might turn out to be a trivial problem, but I am suggesting that we should
> temporarily revert and work it out after the 4.6 release.
>
> Dave
>
>
>

Eliot Miranda-2

Re: Squeak 4.6 -- 2nd release candidate

On Wed, Jul 8, 2015 at 3:29 PM, Levente Uzonyi <[hidden email]> wrote:

There's one difference between the two versions. Using Compiler-eem.300, the following methods are compiled with small frame instead of large frame:

Thanks Levente; that'll be it.

BitBltDisplayScanner>>#displayLines:in:clippedBy:
GradientFillStyle>>#computePixelRampOfSize:
InterpolatedGradientFillStyle>>#computePixelRampOfSize:
NewParagraph>>#clickAt:for:controller:
PackageInfo>>#changeRecordsForMethod:do:
PaintBoxMorph>>#addBrushesOffImage:
PaintBoxMorph>>#addShapeButtonsOffImage:onImage:
PaintBoxMorph>>#addToolsOffImage:onImage:
Paragraph>>#clickAt:for:controller:
PianoRollScoreMorph>>#addNotes
PolygonMorph>>#lineSegmentsDo:
PostscriptCharacterScanner>>#displayLine:offset:leftInRun:
SmalltalkImage>>#appendChangesTo:
StrikeFontSet>>#characters:in:displayAt:clippedBy:rule:fillColor:kernDelta:on:
SuperSwikiServer>>#fastParseEntriesFrom:
TTFontReader>>#processGlyphDataTable:offsets:
TextStyle class>>#fontMenuForStyle:target:selector:highlight:
Unicode class>>#parseCompositionMappingFrom:

Levente

On Tue, 7 Jul 2015, David T. Lewis wrote:

On Tue, Jul 07, 2015 at 05:20:52PM -0700, Eliot Miranda wrote:

Hi David,

On Tue, Jul 7, 2015 at 4:33 PM, David T. Lewis <[hidden email]> wrote:

The problem was introduced in Compiler-eem.300, which does this:

Use the size/emitPushNClosureTemps: api in block generation.

There are two affected methods:

BlockNode>>sizeCodeForEvaluatedClosureValue:
BlockNode>>emitCodeForEvaluatedClosureValue:encoder:

Reverting these two methods fixes the problem.

I don't know the background on this change but my guess would be that
it is something that works on a stack interpreter but not on a context
interpreter, so maybe the methods need to be tweaked to account for the
difference.

It should make no difference to the code produced. It adds a new way of
saying "push N nils" that allows the Sista bytecode set to use its
"pushNClosureNils" bytecode to push several nils in one bytecode. But with
the standard encoder EncoderForV3PlusClosures exactly the same code as the
previous version should be produced.

How do the changes in the compiler cause the crash?

I don't know.

I'm doing brute-force debugging, just rolling the versions back until the
problem goes away.

All I can say with confidence is that those two methods changes, followed by
a system recompile, result in an image that crashes a context interpreter VM.
Reverting these two methods and recompiling brings the image back to a sane
condition.

It might turn out to be a trivial problem, but I am suggesting that we should
temporarily revert and work it out after the 4.6 release.

Dave

best,

Eliot