Re: [Gems-users] Atomic operation implementation


Date: Wed, 18 Oct 2006 10:10:22 -0500
From: Dan Gibson <degibson@xxxxxxxx>
Subject: Re: [Gems-users] Atomic operation implementation
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 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 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.
[← Prev in Thread] Current Thread [Next in Thread→]