Re: [Gems-users] Start Ruby after the simulation is running?


Date: Mon, 3 Mar 2008 10:03:05 -0600 (CST)
From: Xuan Qi <xqi@xxxxxxxxxxx>
Subject: Re: [Gems-users] Start Ruby after the simulation is running?
It clears my confusion. Thanks Luke and Dan!

Best regards,
Xuan Qi


On Mon, 3 Mar 2008, Luke Yen wrote:

>
>    No, it means you shouldn't count them as part of your total execution
> time during simulation.
>
>    Luke
>
> On Mon, 3 Mar 2008, Xuan Qi wrote:
>
> > 4) Be careful to only simulate the important regions of code -- do not
> >
> >   include thread creation / destruction, process forking, etc.
> >
> >   BTW, does this mean GEMS can't simulate multiprogramed or multithreaded
> >   programs? Thanks!
> >
> >   Best regards,
> >   Xuan Qi
> >
> > On Mon, 3 Mar 2008, Dan Gibson wrote:
> >
> >> Have a look at the various headers that come in the LogTM codebase, in
> >> transactions/common/ (GEMS 2.0+) in particular. There should be some
> >> handy macros there intended for this purpose.
> >>
> >> Regards,
> >> Dan
> >>
> >> Philip Garcia wrote:
> >>       Look in the simics reference manual about using the special
> >>       magic instructions.  Using magic breakpoints in the code
> >>       (combined with having set magic-break-enable before running
> >>       the code) will have simics stop execution at that
> >>       instruction.  Just make sure you do a "c 1" after the magic
> >>       instruction before saving the processor's state.  If you
> >>       don't do this, the state will be saved at the magic
> >>       instruction, and telling it to execute again will just cause
> >>       it to break again.
> >> Phil
> >> On Mar 3, 2008, at 1:13 AM, Jim Leek wrote:
> >>
> >>       The wiki FAQ
> >>       (http://www.cs.wisc.edu/gems/doc/wiki/moin.cgi/Frequently_Asked_Questions)
> >>       recommends the following:
> >>
> >>  4) Be careful to only simulate the important regions of code -- do not
> >>
> >> include thread creation / destruction, process forking, etc.
> >>
> >>       That sounds like a good idea.  What is the standard way
> >>       to do this?  It seems like you would have to throw an
> >>       instruction into the benchmark code to halt the
> >>       simulation and drop back to the simics CLI.  Is there
> >>       an instruction to do this?  I guess I could use
> >>       getchar() to do that.  What did the logTM guys do?
> >>
> >>       Jim
> >>       _______________________________________________
> >>       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.
> >>
> >>
> >>     ________________________________________________________________________
> >>  _______________________________________________
> >> 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.
> >>
> >>
> >>
> >>
> >>  --
> >> 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.
> >
> _______________________________________________
> 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.
>
>

[← Prev in Thread] Current Thread [Next in Thread→]