Re: [Gems-users] GEMS 1.3.1 Release Now Available

[Ranjith Subramanian <ranji@xxxxxxxxxxxxx>]

Thanks Dan and Derin for the help.

I have another question though. Has anyone been able to run the 
amd64-version of simics3.0 with gems 1.3? I notice that when ruby is 
compiled with the MOSI_SMP_bcast protocol, the symlink lib in 
$GEMS/simics/home/MOSI_SMP_bcast points to amd64-linux/lib which in turn 
is a symlink to ../../../x86-linux/lib. But the x86-linux directory is 
never created when the amd64-linux version is installed!
Ranjith

Dan Gibson wrote:

> GEMS Users,
>
> GEMS 1.3.1 is now available to address the frequent issues dealing of 
> Ruby's assumption about the name of Simics' physical memory object. GEMS 
> 1.3.1 is a minor change (vs. GEMS 1.3) to Ruby only, but will prevent 
> some compatibility problems when using Simics 3.x, especially unexpected 
> segmentation faults at load-time or init-time.
> The new version is available in the GEMS download directory, 
> http://www.cs.wisc.edu/gems/distribute/.
> GEMS 1.3.1 is available as a complete tarball *OR* as a patch to GEMS 
> 1.3. If you have made modifications to your GEMS 1.3 source, we suggest 
> you use the patch rather than the complete tarball.
> Who should upgrade?
> * Simics 3.x users should consider upgrading to GEMS 1.3.1.
> * Users of both Simics 2.x and Simics 3.x would benefit from upgrading.
>
> Who can/should ignore this upgrade?
> * Users of only Simics 2.x can ignore this update.
> * Users of GEMS 1.2 or earlier should ignore this update.
>
> What files are affected?
> * $GEMS/ruby/module/ruby.c: Now looks for both phys_mem0 and phys_mem 
> objects.
> * $GEMS/ruby/simics/interface.C: Now looks for both phys_mem0 and 
> phys_mem objects.
> Thanks to all those who helped to point out this bug, and possible 
> fixes. Happy simulating.
> Regards,
> Multifacet GEMS Devs
>
>