00187b7bc3
X86 had a private/arch specific request flag called StoreCheck which it used to signal to the TLB that it should fault on a load if it would have faulted had it been a store. That way, you can detect whether a read-modify-write type of operation is going to fail due to a translation problem during the read, and don't have to worry about not doing anything architecturally visible until the store had succeeded, while also making sure not to do the store part if the modify part could fail. It seems that Ruby had hijacked that flag and had an architecture specific check which was looking for a load which was going to be followed by a store. The x86 flag was never intended to communicate that beyond the TLB, and this nominally architecture agnostic component shouldn't be reaching into the ISA specific flags to try to get that information. Instead, this change introduces a new Request flag called READ_MODIFY_WRITE which is used for the same purpose in x86, but in general means that a load will be followed by a write in the near future. With this new globally applicable flag, the ruby Sequencer class no longer needs to check what the arch is, nor does it need to access ISA private data in the request flags. Always doing this check should be no less efficient than before, because checking the arch involved calling into the system object, while checking the flag only requires masking a bit on the flags which the compiler probably already has floating around for other logic in this function. Change-Id: Ied5b744d31e7aa8bf25e399b6b321f9d2020a92f Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48710 Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu> Maintainer: Gabe Black <gabe.black@gmail.com>
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/about, and for more information about building the simulator and getting started please see http://www.gem5.org/documentation and http://www.gem5.org/documentation/learning_gem5/introduction. 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/documentation/general_docs/building 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 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/documentation/general_docs/building for more details and options. 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. If you have questions, please send mail to gem5-users@gem5.org Enjoy using gem5 and please share your modifications and extensions.