I have been making some changes to Ruby on the LogTM protocols,
and I have found a problem that might also affect the original protocol
in some corner cases. When a *non-stallable memory operation* is
executed (such as a casxa, swap or ldda instruction), the
mem_trans->s.may_stall bit is set to 0 by Simics. This means that the
timing model (Ruby) is not allowed to model the timing of the request,
it is directly executed. This case is considered in
SimicsDriver::isUnhandledTransaction().
I dont think this is entirely true. An atomic operation is split into
two components and only the second component is
non-stallable. The first component should be handled as a store by the
logTM implementation and hence
should be properly logged and isolated.
allow stalling certain memory transactions. Anyway, has someone ever
experienced a similar situation and can give some hints on how to avoid
the problem? I would really appreciate some help with the problem.
I believe a similar scenario occurs when Simics comes across double word
load/stores. Simics hands them to
Ruby as two separate single word transactions. Only the first is
stallable. Fortunately, sparc does not handle
misaligned memory operations. Hence double word operations dont span
multiple cache lines and the LogTM
implementation should work correctly. This could be true for multi-word
operations too. I haven't run across
them though.
Jayaram
|
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}