4f4846c532
(1) Atomic Memory Operation (AMO) This patch changes how RISC-V AMO instructions are implemented. For each AMO, instead of issuing a locking load and an unlocking store request to downstream memory system, this patch issues a single memory request that contains a corresponding AtomicOpFunctor to the memory system. Once the memory system receives the request, the atomic operation is executed in one single step. This patch also changes how AMO instructions handle acquire and release flags in AMOs (e.g., amoadd.aq and amoadd.rl). If an AMO is associated with an acquire flag, a memory fence is inserted after the AMO completes as a micro-op. If an AMO is associated with a release flag, another memory fence is inserted before the AMO executes. If both flags are specified, the AMO is broken down into a sequence of 3 micro-ops: mem fence -> atomic RMW -> mem fence. This change makes this AMO implementation comply to the release consistency model. (2) Load-Reserved (LR) and Store-Conditional (SC) Addresses locked by LR instructions are tracked in a stack data structure. LR instruction pushes its target address to the stack, and SC instruction pops the top address from the stack. As specified by RISC-V ISA, a SC fails if its target address does not match with the most recent LR. Previously, there was a single stack for all hardware thread contexts. A shared stack between thread contexts can lead to a infinite sequence of failed SCs if LRs from other threads keep pushing new addresses to this stack. This patch gives each context its private stack to address the problem. This patch also adds extra memory fence micro-ops to lr/sc to guarantee a correct execution order of memory instructions with respect to release consistency model. Change-Id: I1e95900367c89dd866ba872a5203f63359ac51ae Reviewed-on: https://gem5-review.googlesource.com/c/8189 Reviewed-by: Alec Roelke <ar4jc@virginia.edu> Maintainer: Alec Roelke <ar4jc@virginia.edu>
This is the gem5 simulator. The main website can be found at http://www.gem5.org A good starting point is http://www.gem5.org/Introduction, and for more information about building the simulator and getting started please see http://www.gem5.org/Documentation and http://www.gem5.org/Tutorials. To build gem5, you will need the following software: g++ or clang, Python (gem5 links in the Python interpreter), SCons, SWIG, zlib, m4, and lastly protobuf if you want trace capture and playback support. Please see http://www.gem5.org/Dependencies for more details concerning the minimum versions of the aforementioned tools. Once you have all dependencies resolved, type 'scons build/<ARCH>/gem5.opt' where ARCH is one of ALPHA, ARM, NULL, MIPS, POWER, SPARC, or X86. This will build an optimized version of the gem5 binary (gem5.opt) for the the specified architecture. See http://www.gem5.org/Build_System for more details and options. With the simulator built, have a look at http://www.gem5.org/Running_gem5 for more information on how to use gem5. The basic source release includes these subdirectories: - configs: example simulation configuration scripts - ext: less-common external packages needed to build gem5 - src: source code of the gem5 simulator - system: source for some optional system software for simulated systems - tests: regression tests - util: useful utility programs and files To run full-system simulations, you will need compiled system firmware (console and PALcode for Alpha), kernel binaries and one or more disk images. Please see the gem5 download page for these items at http://www.gem5.org/Download If you have questions, please send mail to gem5-users@gem5.org Enjoy using gem5 and please share your modifications and extensions.