Tim Rowledge wrote:
> Julian Fitzell <julian at beta4.com> wrote:
> 
> 
>>The other problem then turned out to be that the older VMMaker in Ian's 
>>image seemed to produce a VM that wouldn't run the new images.  So I 
>>need to go back up to the newest VMMaker, but Ian has patches applied 
>>againt the old one and I have no idea whether I still need to apply 
>>those or not.  And I also have no idea how new an image I need to be 
>>using to build the new VM.
> 
> I'd love to know what patches to VMMaker are involved. I don't recall
> any recent changes that should affect runnability and if there have
> been we need to find them soon.

Well, his configured image is at 
http://www-sor.inria.fr/~piumarta/squeak/unix/devel/vmm.tar.bz2

There a VMMUnix-ikp for sure.  There were also a bunch of other patches 
in his working directory and I wasn't sure which of those might be 
needed or might be incorporated into VMMaker (keep in mind I'm a VMMaker 
newbie :) ).

They may all be included in the new VMMaker, but that was what I was 
completely unable to determine.

> The only almost-recent change I can see affecting performance is the
> move to keeping (most of) the globals in a big array. IIRC Ian had
> changed to making use of that quite a while ago. 

Yeah, I saw references to that in the mail archive.  The code does 
indeed have a foo array with globals in it.  I managed to get a VM 
compiled using the 3.6g-2 distribution code with ned's floatbug patch 
and the truncate primitive fix I reposted earlier today.  This VM still 
seems to run at about half the speed of Ian's binary so I guess it must 
be difference of gcc versions (though it seems depressing that the speed 
dropped by 1/2 from 3.3.1 to 3.3.3).

This image at least runs the new images and doesn't give primitive 
failed errors on the truncate prim so I think I'm going to just start 
using it.  Only so much time I can spend on these things with deadlines 
looming...

>>And finally, this generated source compiles fine on Linux but appears 
>>not to compile on Solaris (and I've compiled the 3.6-g-2 sources on the 
>>same Solaris box just fine).  I don't know if this is a problem with 
>>Ned's branch or with the old VMMaker (I haven't yet tried a Solaris 
>>compile of a ned-branch/new VMMaker source tree).  The error I get is:
>>
>>gnu-interp.c: In function `primitiveResponse':
>>gnu-interp.c:16425: `primitiveIndex' undeclared (first use in this function)
>>gnu-interp.c:16425: (Each undeclared identifier is reported only once
>>gnu-interp.c:16425: for each function it appears in.)
> 
> primitiveIndex is one of the globals that sh/w/ould be in the array
> 'foo' and so this suggests to me that soemthing is wrong with that
> mechanism here. Look at the interp.c file and see where primitiveIndex
> is declared and where it is used. In my latest interp.c it is declared
> within 'foo' and first used in addNewMethodToCache as
> foo->primitiveIndex.

Yeah, mine is defined and first used in the same places.  When I looked 
at the code earlier, I couldn't for the life of me see why the error was 
coming up and I still can't.  But the source I generated from the 3.6g-2 
release instead of the CVS code seems to have compiled ok on Solaris now.

I just tried a diff between interp.c in two the trees and, except for 
variable definition order differences, the only major changes I can pick 
out (on a quick skim) are that the one generated from CVS with Ian's vmm 
image (old VMMaker) includes emphemeron stuff and a bunch of references 
to displayBits.  The one generated from the 3.6g-2 release using the 
newest VMMaker doesn't have either of those.

If anyone wants a copy of the tree or diffs or anything, I'm happy to 
provide.  But it's working (albeit slowly) now so I don't think I'll 
monkey with it any more.

Julian