[Gems-users] retry hack in ATMTP/Rock

["salil pant" <floydian27@xxxxxxxxx>]

I am a little confused about the retry hack being used in the ATMTP/Rock simulator.
This is what I have understood so far :- you catch exceptions within Transactions and detect their type.
Inside the Core_Exception hap, however, you change the PC to point to a new location which contains the RETRY instruction.
What does this do? Does the code inside the exception handler execute or not ?
what is the use of the retry  ?  I ask this  mainly because we abort when the exception completes anyway and we change the PC back to the beginning of the transaction.
Why not just let the execution handler finish and then simply rollback using a checkpoint and switch the PC back to the start of the transaction ?
What am I missing here ?

salil

On Thu, Jul 24, 2008 at 7:03 PM, salil pant <floydian27@xxxxxxxxx> wrote:

Hi, I have been using the LogTM system in GEMS ( 1.2 ) . I have been working on implementing some extra features for transactional memory, but I keep running into exceptions within transactions that "hang" my system. The processor starts taking a lot of window spill/fill exceptions and then is not able to get out of the transaction.
 Using SIM_get_exception_name I was able to get the type of exception that starts the problem  - fast_data_access_mmu_miss. This seems to be a dtlb miss exception.
I followed some of the techniques in the previous posts , namely warming up the TSB/ TLB by running the benchmark once in SIMICS without RUBY installed or touching the data structure before the transaction. This has not helped me so far.
I guess my question is - Are there any more solutions to avoid getting tlb miss exceptions within transactions ?
 Can we run transactions from benchmark suites like Splash/STAMP , which can be really long and can take tlb exceptions, without crashing ?

Do the later versions of GEMS  have a solution for this ? I have been reading some of the SimicsHypervisor code in the latest versions and that seems to include callbacks to detect tlb misses. Have the callbacks been implemented to tackle this issue ? and is that the only thing needed if I were to use them in my version ?

thanks
salil