A minor correction to Derek's sequence...
6) Simics sends the reference again to Ruby via makeRequest. Ruby
detects a duplicate ref, it checks to see that the ref is done
and returns '0' to Simics which tells Simics to complete the instruction.
Look for 'new request' and 'dup request' in SimicsProcessor. That's
where most of the logic for
SIMICS interactions lies...
makeRequest() in SimicsProcessor.C
in TransactionSimicsProcessor.C
-> startingMemRef(): Attempting to start a new memory reference to the
underlying memory system.
-> completedMemRef(): Underlying memory system has completed the
memory reference either successfully or detected a transactional conflict.
UNSTALL SIMICS
Duplicate makeRequest() from SIMICS
-> readyToRetireMemRef(): Ready to retire the memory reference in SIMICS.
-> processLogStore
-> canRetireMemRef(): Should we retire the memory reference? Yes,
Retry or Trap
if Yes, return '0' to SIMICS, If Retry return 'Retry' to SIMICS. If
'Trap', ask SIMICS to Trap.
Check
http://www.cs.wisc.edu/gems/doc/gems-wiki/moin.cgi/LogTM_Code_Overview
for more details
Jayaram
Derek Hower wrote:
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.
_______________________________________________
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}