dc328d00eb
The call to initCPU was moved into initState in the base CPU class since it should only really be called when starting a simulation fresh. Otherwise checkpointed state will be loaded over the state of the CPU anyway, so there's no reason to set up anything else. Unfortunately that made it possible for the System level initialization and the CPU initialization to happen out of order, effectively letting initCPU clobber the state the System might have set up to prepare for executing a kernel for instance. To work around that issue, the call was moved to init which would necessarily happen before initState, restoring the original ordering. This change moves the change *back* into initState, but of the System class instead of the CPU class. This makes it possible to guarantee that OS initialization happens after initCPU since that's also done by System subclasses, and they control when they call initCPU of the base class. This also slightly simmplifies when initCPU is called since we shouldn't need to check whether a context is switched out or not. If it's registered with the System object, then it should be in a currently swapped in CPU. This also puts the initCPU and startupCPU calls right next to each other. A future change will take advantage of that and merge the calls together. Also, because there are already ISA specific subclasses of System which already have specialized versions of initState, we should be able to move the code in initCPU and startupCPU directly into those subclasses. That will give those subclasses more flexibilty if, for instance, they want all CPUs to start running in the BIOS like they would on a real system, or if they want only the BSP to be active as if the BIOS had already paused the APs before passing control to a bootloader or OS. This will also remove another two TheISA:: style functions, reducing the number of global dependencies on a single ISA. Change-Id: Ic56924660a5b575a07844a198f69a0e7fa212b52 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24903 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> Tested-by: kokoro <noreply+kokoro@google.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 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/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.