[Cuis-dev] Cuis stable releases - last interpreter VM image?

Juan Vuletich JuanVuletich at zoho.com
Fri Nov 3 09:31:37 CDT 2017


On 11/2/2017 9:33 PM, David T. Lewis via Cuis-dev wrote:
> I think I see the issue, but do not yet know what to do about it.
>
> For Spur, Eliot changed Object>>instVarAt: and Object>>instVarAtPut: to use
> primitives 173 and 174 rather than primitives 73 and 74.
>
> > From #intializePrimitiveTable in VMMaker for Cog:
>
> 		"SpurMemoryManager primitives"
> 		(170 primitiveAsCharacter)
> 		(171 primitiveImmediateAsInteger)
> 		(172 primitiveFetchNextMourner)
> 		(173 primitiveSlotAt)		"c.f. (73 primitiveInstVarAt)"
> 		(174 primitiveSlotAtPut)	"c.f. (74 primitiveInstVarAtPut)"
> 		(175 primitiveBehaviorHash)
> 		(176 primitiveMaxIdentityHash)
> 		(177 primitiveAllInstances)
> 		(178 primitiveAllObjects)
> 		(179 primitiveFail) "reserved for primitiveAllInstancesOfAny"
> 		(180 primitiveGrowMemoryByAtLeast)
> 		(181 primitiveSizeInBytesOfInstance)
> 		(182 primitiveSizeInBytes)
> 		(183 primitiveIsPinned)
> 		(184 primitivePin)
>
> These were listed as "SpurMemoryManager primitives", and do not exist in the
> interpreter VM, which currently does this:
>
> 		"Sound Primitives (170-199) - NO LONGER INDEXED"
> 		(170 174 primitiveFail)
>
> The sound primitive assignments are now obsolete, and Eliot repurposed them for
> Spur primitives. Currently they remain as #primitiveFail in the interpreter VM.
>

Yes, thanks! It took you way less than a week to identify the issue :)

Googled a bit on the primitive number change, to better understand. It 
is not a primitive number change, but a change in the primitives to 
avoid a specific performance penalty in Spur, as Eliot says at 
http://forum.world.st/Some-test-where-Spur-more-slow-than-Cog-td4867810.html#a4867888

> We can add primitiveInstVarAt and primitiveInstVarAtPut into the 173 and 174
> numbered primitive slots in the interpreter VM. This will fix the problem, but
> it requires people to compile their own updated VMs, so I do not know if it is
> a practical solution in the near term.
>
> Dave

Adding primitives 173 and 174 (with the new semantics) to InterpreterVM 
is a possible approach, but no existing Squeak/EToys/Cuis images would 
benefit, so it is hard to justify the effort. A better solution is to 
use the appropriate primitives for each VM, as Cuis already does with 
Time primitives, where different primitives were added to VMs along time.

I already pushed change #3207 to GitHub and updated all the images. Now 
Cuis works OK on InterpreterVM!

Cheers,

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
@JuanVuletich





More information about the Cuis-dev mailing list