Re: [Gems-users] logTransactionStore

["Derek Hower" <drh5@xxxxxxxxxxx>]

No, makeRequest is only called once.  Perhaps "replay" is not the
correct word to be using here.  This is the progression:

1.  Simics notices that the next instruction it is about to execute
makes a memory reference.
2.  Simics tells Ruby about the reference (by giving it a memory_transaction_t).
3.  Ruby processes the transaction (via makeRequest) and places the
next event related to that transaction in the event queue.
4.  Ruby returns to Simics, telling it to stall indefinitely (because
at this point Ruby doesn't know when the instruction will complete).
5.  Eventually Ruby determines that the memory transaction completes.
It then tells Simics to unstall.
6.  Simics finally executes the instruction, updating the target system's state.

-Derek

On Thu, Oct 9, 2008 at 12:01 PM, Lois Orosa Nogueira <lois.orosa@xxxxxx> wrote:
> I understand that is simics (not ruby) who replay the instruction (?).
>
> Then, in SimicsProccesor.C when arrive a duplicate request  some actions are
> doing, why do not you ignore that replay in ruby and take this actions in
> the first request?
>
> I see that the ruby.C calls cycles_t ruby_operate, that call
> mh_memorytracer_possible_cache_miss (in commands.C), that call the
> makeRequest function in simicsDriver. Then I understand that this functions
> are executed only two times (one for the replay), is this correct? (the
> makeRequest functions executed only two times)
>
> Thanks
> Lois
>
> Derek Hower escribió:
>
> Ruby will replay an instruction only once (ignoring for now
> transactional rollback and replay).  Ruby initially stalls an
> instruction indefinitely because at the time the instruction issues,
> Ruby doesn't know how long the instruction will take.  After Ruby does
> timing calculations, it will explicitly unstall the instruction when
> the instruction is supposed to commit.
>
> For transactional memory, Ruby follows the same model until a
> transaction needs to abort.  At that time, the Simics state is rolled
> back from the log using standard Simics API calls, and then Ruby
> continues as normal to replay the transaction.
>
> -Derek
>
> On Thu, Oct 9, 2008 at 5:38 AM, Lois Orosa Nogueira <lois.orosa@xxxxxx>
> wrote:
>
>
> Thanks Jayaram,
>
> I have other question. In
> https://lists.cs.wisc.edu/archive/gems-users/2007-May/msg00015.shtml  Mike
> Marty said:
>
> The model is that Ruby will stall a Simics processor indefinitely until a
> request finishes.  Then it unstalls Simics and Simics will "replay" the
> stalled instruction
>
> How many times replay simics the stalled instruction? Does it depends on the
> instruction? Can anybody explain a little more that happeds in this replays
> of the instructions??
>
> In a ST_XACT, when the addUndoLogEntry is called (in the replay??)?
>
>
> Thanks in advance
> Lois
>
> Jayaram Bobba escribió:
>
> logTransactionStore is not used. search for addUndoLogEntry in
> TransactionSimicsProcessor.C instead...
>
> Jayaram
>
> Lois Orosa Nogueira wrote:
>
>
> Hi list,
>
> in log_tm, where it is done the log transaction store ??
>
>  I don't see where the function
> TransactionInterfaceManager::logTransactionStore is called when there is
> a ST_XACT
>
> Thanks
> Lois
> _______________________________________________
> 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.
>
>
>
> _______________________________________________
> 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.
>
>
>
> _______________________________________________
> 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.
>
>
>