Thanks, Dan. All of that is consistent with my experience.
I certainly don't expect UW folks to make this work on all
possible systems -- the variables are innumerable. I think
y'all are doing a great job of support with the resources
you have.
I spoke up this time because I didn't want the GEMS
community to think that everyone is using Simics 3.x at this
point.
...Greg
Dan Gibson wrote:
Greg (+list),
The compiler version issue is a really, really difficult problem. We
have seen this problem at various times, on the list and internally, and
we invariably get the same response from Virtutech: Upgrade.
My current theory on this is that Simics 2.x (or 3.x) is compiled
against ABI x, GEMS is compiled to ABI y according to the setup of the
host machine, and both GEMS and Simics end up /using/ ABI z at runtime,
where in general x!=z and y!=z (though usually y==z). Hence, (at least)
two flavors of libc interact, and eventually the heap gets smashed.
Unfortunately, I don't know why it works for some folks and not for
others -- memory corruption is a pretty subtle problem as you know.
So why not upgrade? There is no short answer, so here's the long one.
1) GEMS-users (including ourselves) have a lot of scripts that are not
forward compatible (though checkpoints ARE from 2.x to 3.x).
2) We have had some indication that GEMS+Simics2 is faster than
GEMS+Simics3 for some workloads
3) Upgrading is a big pain and we don't have a lot of free graduate
students available to make the change
4) Changing Simics version has the nasty side effect of changing
results... and no one wants to admit mid-thesis that results are
sensitive to something like that.
However, as I said in my earlier post, we are looking into Simics 4.0
compatibility for GEMS right now. It will not be available for use in
classes this semester. In fact, from my 'experience' in porting GEMS to
3.0, I won't guarantee it'll /ever/ be available. But, we're looking
into it and we request and appreciate patience from our user community.
Regards,
Dan
On Mon, Feb 2, 2009 at 11:18 AM, Greg Byrd <gbyrd@xxxxxxxx
<mailto:gbyrd@xxxxxxxx>> wrote:
For the record, I have not been able to get GEMS to work
"just fine" with Simics 3.x. The main issue is the versions
of compilers used to compile and link GEMS vs. what's used
for Simics.
I know others have had success, but my experience has not
been good. I was hoping to make the move to 3.0 for my
class this semester, but I ended up sticking with 2.x.
So I'm unhappy to see 2.x go away, but I understand why and
hopefully will figure out a way to work around it.
...Greg
PS. I found the right mix of compilers to get everything to
link, but then ruby0.init crashes immediately with a bad
address passed to free(). If anyone has seen similar
behavior and figured out a fix, let me know. I'm somewhat
constrained by a university computing environment that's
largely out of my control, so please don't send me fixes
like "reinstall Linux with this patch."
Abdullah Kayi wrote:
> Hi Dan,
>
> FYI, Virtutech already suspended new Simics 2.x licenses. However, as
> you mentioned Simics 3.x works fine with GEMS, the only problem
would be
> the checkpoint scripts.
>
> Regards,
>
> AK
>
> On 2/2/09 11:52 AM, "Dan Gibson" <degibson@xxxxxxxx
<mailto:degibson@xxxxxxxx>> wrote:
>
> Hi,
>
> We're working internally on Simics 4.0 compatibility and testing
> right now. As with a lot of these graduate-student driven
> projects... its a slow process.
>
> The good news is that there is no real rush for current GEMS
users
> to upgrade from Simics 3.0 to 4.0 on their own. There is some
> concern that Virtutech may be considering suspending
availability of
> new Simics 2.x licenses, but GEMS works with Simics 3.x already.
>
> Regards,
> Dan
>
> On Mon, Feb 2, 2009 at 10:46 AM, Yangchun Luo
<yluo@xxxxxxxxxx <mailto:yluo@xxxxxxxxxx>> wrote:
>
> Hi,
>
> Since Simics 4.0 is released by Virtutech, I wonder if it is
> also compatible with GEMS 2.1?
> And how urgent is it for GEMS users to upgrade from
Simics 3.0.x
> to 4.0?
>
> Thanks!
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx <mailto:Gems-users@xxxxxxxxxxx>
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding
> "site:https://lists.cs.wisc.edu/archive/gems-users/"; to
your search.
>
>
>
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx <mailto:Gems-users@xxxxxxxxxxx>
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding
"site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
>
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx <mailto:Gems-users@xxxxxxxxxxx>
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding
"site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
--
http://www.cs.wisc.edu/~gibson [esc]:wq!
------------------------------------------------------------------------
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}