Re: [Gems-users] Atomic operation implementation

[Dan Gibson <degibson@xxxxxxxx>]

Let me address each sub-question independently (below):

hongxia sun wrote:
> Dan,
>  
> Thank you for your help!
>  
> But there are still some questions on this topic. I looked up in 
> SIMICS doc and found some explanation about /Atomic Instruction/ in 
> *simics-micro-architectual-interface*. It said that "MAI handles this 
> by */locking a ram region/* at a /configurable granularity/ when the 
> first access is issued. The lock is released as soon as the second 
> access is finished or if the instruction is squashed. Any * 
> conflicting transaction to the same memory region* issued between the 
> two by */any/* */processor/* will *stall* until the lock is released." 
> Does it means any atomic operation is handled by SIMICS itself?
Yes, it does. However, GEMS does NOT use the Simics MAI (architectural
interface). As I remember, the non-MAI implementation is as I described
in my previous email.

Regardless of how Simics actually implements the atomicity, Ruby is
responsible to emulate the proper timing only. Since Ruby would cause a
stall on a coherence action anyway, Simics should never self-stall
(assuming a standard coherence protocol).

> SIMICS will control the conflicting memory accesses between 
> multiprocessors? Is it best to set the *lock granularity* as the *size 
> of a cache line*?
I cannot comment on how to best use MAI -- since GEMS expects you to NOT
be using MAI, I would suggest ignoring MAI parameters.
>  
> I know that in our currently simulation, we need to do nothing special 
> to support atomic operation. However, in a real system, no such 
> mechanism to control atomic operation between multiprocessors. For 
> example, in MIPS, it implements spin lock through LL-SC. All the 
> processors can try LL-SC to acquire the lock, and they will check 
> whether there are any other stores between their own LL-SC by some 
> special hardware themselves. Is it still nothing to do with Cache 
> Coherence Protocol?
In theory, there is no need to modify the coherence protocol. The LL
will acquire read permissions and the SC will acquire write permissions.
Whether the SC actually writes a value is essentially a processor-side
option--the processor can elect to not write into cache.
> Do we still need *not* to add any special mechanism in Cache Coherence 
> Protocol to support such atomic instructions?
Notably, LL/SC doesn't require any special atomicity guarantee over
those needed by CAS -- the LL can be treated as a regular load, and the
SC is something like a compare-and-swap (SPARC CAS). As I mentioned
before, CAS already works with existing protocols.  In fact, some
obstruction-free algorithms on SPARC use CAS as the conditional
component of LL/CS.
>  
> Thanks a lot!
>  
> Best Regards,
> Hongxia
>  
> 2006/10/18, Dan Gibson <degibson@xxxxxxxx <mailto:degibson@xxxxxxxx>>:
>     Hongxia,
>
>     GEMS (Ruby in particular) treats all ATOMIC-type operations as
>     stores, with the exception of LDDA. Also, Simics only allows the
>     FIRST member of an atomic action to stall, though both will appear
>     to Ruby in the same "cycle" -- that is, a read-modify-write
>     operation may appear to Ruby as two atomics in a row, but only the
>     first will be stallable and therefore the operations will occur
>     atomically.
>
>     In short, there is no need to make a special modification to your
>     protocol to support the regular set of atomics provided by
>     UltraSPARC III+.
>
>     Regards,
>     Dan Gibson
>
>     hongxia sun wrote:
> >     Dear all,
> >      
> >     In our recently simulation on GEMS, we are trying to implement
> >     our protocol based on MSI_MOSI_CMP_directory protocol.
> >      
> >     We found there was a "CacheRequestType:ATOMIC" can come from
> >     mandatory queue which communicated with processor, but no actual
> >     support on such atomic operation in protocol.
> >      
> >     We tried to support such atomic operation in our protocol.
> >     We wondered whether such atomic memory access was tranfer by
> >     SIMICS to RUBY through files in /ruby/simics/.
> >      
> >     We noticed that in GEMS home page, the description of GEMS Key
> >     Features said "Leverages the power of Virtutech Simics
> >     <http://www.virtutech.com/products/simics.html> to simulate a
> >     */Sparc/ *multiprocessor system. " Does it mean that GEMS only
> >     support */Sparc/* atomic instruction? Or SIMICS can split atomic
> >     instructions of different processors into the same memory access
> >     operation to GEMS? How can we implement atomic operation in our
> >     protocol? Where could we start from?
> >      
> >     Any help will be greatly appreciate!
> >     Thank you!
> >      
> >     Best Regards,
> >     Hongxia Sun
> >     ------------------------------------------------------------------------
> >
> >     _______________________________________________
> >     Gems-users mailing list
> >     Gems-users@xxxxxxxxxxx <mailto: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/
> >      <https://lists.cs.wisc.edu/archive/gems-users/>" to your search.
> >
> >       
>     _______________________________________________
>     Gems-users mailing list
>     Gems-users@xxxxxxxxxxx <mailto: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!