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

David T. Lewis lewis at mail.msen.com
Thu Nov 2 19:33:18 CDT 2017


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.

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


On Wed, Nov 01, 2017 at 12:42:30PM -0300, Juan Vuletich wrote:
> Hi David,
> 
> On 10/31/2017 8:06 PM, David T. Lewis via Cuis-dev wrote:
> >Hi Hannes,
> >
> >On Tue, Oct 24, 2017 at 10:25:35AM +0200, H. Hirzel via Cuis-dev wrote:
> >>Hello
> >>
> >>I am looking for a recent Cuis image which may be run with an
> >>interpreter VM (e.g. on old hardware) [1][2].
> >>
> >>There is 'active development'
> >>
> >>     https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
> >>
> >>and 'stable releases'
> >>
> >>    https://github.com/Cuis-Smalltalk/Cuis-Smalltalk
> >>
> >>Which of the different images there may still be run with an interpreter 
> >>VM?
> >>
> >There are currently three image formats that are being actively supported 
> >in Cuis.
> >Checking this with the ckformat utility 
> >(http://wiki.squeak.org/squeak/6290), we
> >have this in Cuis:
> >
> >    lewis at lewis-Gazelle-Pro:~/squeak/Cuis/Cuis-Smalltalk-Dev$ for i in 
> >    *.image; do echo $i `ckformat $i`; done
> >    Cuis5.0-3196-32.image 6521
> >    Cuis5.0-3196.image 68021
> >    Cuis5.0-3196-v3.image 6505
> >
> >The 68021 format image is 64-bit Spur, 6521 is 32-bit Spur, and 6505 is the
> >original V3 image format that works with StackInterpreter, Cog, and the 
> >traditional
> >interpreter VM.
> 
> Thanks for the explanation!
> 
> >Checking this on my Ubuntu system with interpreter VM and Cog, the V3 Cuis
> >image works on Cog, but it no longer works on interpreter VM due to an
> >apparent problem with display handling.
> >
> >The V3 Cuis image used to work with interpreter VM, and I am not sure when 
> >this
> >problem began happening for the combination of interpreter VM and Cuis V3 
> >image
> >(which I think was probably what you were originally asking about).
> >
> >My first guess would be that Cuis has recently started to use some 
> >primitive
> >that is present in the Cog VM but not yet present in the interpreter VM.
> 
> Oh. I wasn't aware of all this at all. Somehow I forgot that Cuis could 
> and should run on the Interpreter VM!
> 
> >If anyone has any suggestions as to what may have changed in Cuis with 
> >regard
> >to using new primitives or using Cog specific features, I will try to find
> >the problem and fix it (but right now I do not have much time and I do not
> >really know where to look).
> 
> Ok. It wasn't easy! Debugging image startup is tricky!
> 
> For this debugging, I used Squeak-4.10.2.2614-linux_i386.tar.gz from 
> http://www.squeakvm.org/unix/ running on Debian 8.
> 
> The problem is in
> Character >> #nonImmediateNumericValue
>     "Answer the numeric value of the receiver, if instances happen to 
> be regular (i.e. not in Spur)"
>     ^self instVarAt: 1
> 
> The reason for this weird implementation and not just answering the 
> instance variable is only to avoid a (harmless) Undeclared in the Spur 
> variants (where Character is an immediate class).
> 
> I could make Cuis run on this VM, by starting it first in CogV3, change 
> the method to answer the ivar, and saving the image. This hacked image 
> starts normally with the Interpreter VM, but evaluating, for example, 
> '3 at 4 instVarAt: 1' fails the primitive. It looks like in this VM, 
> #instVarAt: always fails... (and could also break other senders).
> 
> David, can you please take a look?
> 
> Thanks!
> 
> -- 
> Juan Vuletich
> www.cuis-smalltalk.org
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
> @JuanVuletich
> 



More information about the Cuis-dev mailing list