Mac PPC Carbon VM resuscitation part 2: status and two questions

 
Hi all,

Continuing down the dusty road of bringing the Mac Carbon VM back to  
life on PowerPC for research and educational purposes.  Here's a  
status update and two questions.

First, status update:
I've concluded that the VM will continue to build with very few  
changes up to VMMaker 4.4.14, but then a VM that locks up at  
interpret() as of 4.4.15.  I then fast-forwarded to VMMaker 4.7.8 and  
again have a working VM.  But, this has required a few changes to  
methods and I have had to stop building a few more plugins (to be  
expected, I think!), namely B3DEnginePlugin and  
SoundGenerationPlugin.  The VM built with VMMaker 4.7.8 passes more  
tests in Squeak 4.6 than those built with previous versions, but also  
happens to be failing one test which may be consequential:  
LargeNegativeIntegerTest>>#testMinimumNegativeIntegerArithmetic

I've been working lately within a 4.6 image converted to 6504 format  
(thanks for the tip, Dave!).  Note that my build product, even at  
4.7.8, still can't natively launch & interpret a 6505-format image  
like the release version of 4.6 from files.squeak.org.  Nor can it  
launch & interpret Squeak5.2-V3-18216.image.  Squeak5.2-V3-18216.image  
is already in 6504 format, so I suspect something else to be at fault  
(I just force-quit it now, and found it having trouble at  
_primDigitMultiplyNegative and _cDigitMultiplylenwithleninto).  May be  
worth further research on my part.

By VMMaker 4.7.8, my VM build workspace is as follows:

vmm := (Smalltalk at: #VMMaker) default.
" We can't cascade here.  Maybe was fixed in later versions."
vmm deleteEntireGeneratedTree.
vmm makeAllModulesInternal.
vmm internalModules removeAll: #( ADPCMCodecPlugin B3DEnginePlugin  
ClipboardExtendedPlugin CroquetPlugin FFIPlugin FloatMathPlugin  
FileCopyPlugin ImmX11Plugin LocalePlugin Mpeg3Plugin QuicktimePlugin  
SlangTestSupportSSIP SlangTestSupportPlugin SoundGenerationPlugin  
TestOSAPlugin).
vmm generateEntire.
((Smalltalk at: #Gnuifier) on: (FileDirectory default fullName), '/src/
vm') gnuify.

The script I used for getting a VMMaker build image going in a "stock"  
Squeak 4.5/4.6 image is attached.   It was based off of (and, I  
believe, clarifies or codifies) the instructions found in platforms/
Mac OS/vm/Documentation/readme.txt  re: proper load order.






Question 1:

InterpreterPrimitives>>#signed64BitValueOf:
uses usqLong which wasn't defined in any of my platform support code:

value := 0 - (self cCoerce: value to: 'usqLong').

I changed it to:

value := 0 - (self cCoerce: value to: 'unsigned sqLong').

...does that seem equivalent?

Should I have usqLong defined somewhere in my platform support code?  
It is used more heavily in opensmalltalk-vm, but I can't seem to find  
where it is defined over there, either.

Question 2:

LargeIntegersPlugin>>#digitMontgomery:times:modulo:mInvModB:
was introduced in VMMaker 4.4.20 (VMMaker-dtl.233) and later bugfixed  
in VMMaker 4.5.3 (VMMaker-dtl.239)

However, this method calls "self error:"  as follows:

        firstLen <= thirdLen ifFalse: [^self error: 'firstLarge must be less  
than thirdLarge'].
        secondLen <= thirdLen ifFalse: [^self error: 'secondLarge must be  
less than thirdLarge'].
        (mInv >= 0 and: [mInv <= 255]) ifFalse: [^self error: 'mInvMod256  
must be between 0 and 255'].

which results in an undefined symbol _error when building this VM.

What would be the proper way to address this?  Find a place to  
implement error() in the VM cross/ or platform/ sources (or steal from  
newer support code)?  Or to change the call to self error: to  
something else?

To get the VM building, I've just hand-patched LargeIntegers.c as  
follows:

if (!(firstLen <= thirdLen)) {
        /* return error("firstLarge must be less than thirdLarge"); */
        return interpreterProxy->success(false);
}
if (!(secondLen <= thirdLen)) {
        /* return error("secondLarge must be less than thirdLarge"); */
        return interpreterProxy->success(false);
}
if (!((mInv >= 0) && (mInv <= 255))) {
        /* return error("mInvMod256 must be between 0 and 255"); */
        return interpreterProxy->success(false);
}

Lastly:  I'm tempted to ask if anybody ever tried controlling the  
Xcode project via AppleScript, back when Xcode was still a big part of  
building the Mac or iOS VM.  Maybe maximum effort with minimum payoff,  
but could be interesting or fun to automatically enable/disable plugin  
sources based on VMMaker(Tool) selections, and automatically trigger  
build/clean from within the Squeak image.

Thanks,
a Tim

 
Hi Tim,

Nice to get this update from you, thanks :-)

I cannot answer your specific questions, but here are a couple of
things that might help.

> Note that my build product, even at  
> 4.7.8, still can't natively launch & interpret a 6505-format image  
> like the release version of 4.6 from files.squeak.org.

I have never actually tested the case of a big-endian interpreter VM
loading a 6505 image that was saved from a little-endian machine. I tried
to write the logic around ContextInterpreter>>normalizeFloatOrderingInImage:
in anticipation of this, but I had no way to test it. So it is very
possible that I may have gotten something wrong. But I think that I made
later changes to this logic, so if possible I would prefer to debug
the problem using a more up to date VMMaker.

You seem to be seeing some problems that may be related to mismatches
between the VMMaker generated code and the platforms support code.
In general, there are not a lot of dependencies between the two over
short time windows, but if you are trying to build with version X of
the VMMaker sources against version Y of the platform sources from
the Subversion repository, then things are going to get out of whack
if the two versions are not reasonably close.

There is no real control around this, but if you are trying to make
a VM with version X of VMMaker, then you would probably want to check
out a set of platforms source from Subversion with similar time
stamp, or from maybe 6 to 12 months earlier.

Overall, you are doing a stepwise progression from the old VM version,
moving forward one chunk at a time. That is exactly how I would have
attacked the problem. But with the advantage of my knowing a few things
about what changed over the years, I would actually suggest that you
try a short-cut to save some steps. My advice is to set aside your
stepwise progression for a moment, and try going directly to the
latest versions of VMMaker and the SVN support code, and see if that
gets you reasonably close to a working VM. I do not know if this will
work, but if it does it will save you some time.

Dave

Oe Sat, Jul 25, 2020 at 11:02:17AM -0700, Tim Johnson wrote:

 
Hi Dave,

On Jul 25, 2020, at 1:57 PM, David T. Lewis wrote:

OK.  And yes, I saw there were some updates to this functionality over  
time, even through the 4.4 to 4.7 versions of VMMaker.

This is an interesting point.  I had (mistakenly) thought that SVN was  
frozen in time, around the point when the GitHub repo began and (I  
believe) some/all of its history was imported there.

But now that I am looking at the current SVN repo (rather than the  
circa-2010 snapshot fork I'd found elsewhere on GitHub and was using),  
I am finding all kinds of treasures. The files in Glue/image seem  
particularly interesting at first glance.  I had a vague decade-old  
memory that these files existed somewhere.

Now I need to brush up on my SVN skills.  :)

Thanks for this.  I'll see what I can do with it.

Tim