The Request::NO_ACCESS flag instructs the cpu model to not issue
the request to the memory port.
While Atomic and Timing CPU models properly implement it [1], [2],
* MinorCPU is not looking at the flag
* O3CPU is looking at the flag only in case of a nested transaction
start/commit
This patch is extending NO_ACCESS support to all memory instructions.
This is achieved by using the localAccess callback in the Request object.
Handling of nested hardware transactions in the O3 LSQUnit is moved within
the local accessor callback
[1]: https://github.com/gem5/gem5/blob/v21.1.0.2/\
src/cpu/simple/timing.cc#L318
[2]: https://github.com/gem5/gem5/blob/v21.1.0.2/\
src/cpu/simple/atomic.cc#L396
Change-Id: Ifd5b388c53ead4fe358aa35d2197c12f1c5bb4f2
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56591
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: ZHENGRONG WANG <seanyukigeek@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
The BaseCPU type had been specializing itself based on the value of
TARGET_ISA, which is not compatible with building more than one ISA at a
time.
This change refactors the CPU models so that the BaseCPU is more
general, and the ISA specific components are added to the CPU when the
CPU types are fully specialized. For instance, The AtomicSimpleCPU has a
version called X86AtomicSimpleCPU which installs the X86 specific
aspects of the CPU.
This specialization is done in three ways.
1. The mmu parameter is assigned an instance of the architecture
specific MMU type. This provides a reasonable default, but also avoids
having having to use the ISA specific type when the parameter is
created.
2. The ISA specific types are made available as class attributes, and
the utility functions (including __init__!) in the BaseCPU class can
refer to them to get the types they need to set up the CPU at run time.
Because SimObjects have strange, unhelpful semantics as far as assigning
to their attributes, these types need to be set up in a non-SimObject
class, which is then brought in as a base of the actual SimObject type.
Because the metaclass of this other type is just "type", things work
like you would expect. The SimObject doesn't do any special processing
of base classes if they aren't also SimObjects, so these attributes
survive and are accessible using normal lookup in the BaseCPU class.
3. There are some methods like addCheckerCPU and properties like
needsTSO which have ISA specific values or behaviors. These are set in
the ISA specific subclass, where they are inherently specific to an ISA
and don't need to check TARGET_ISA.
Also, the DummyChecker which was set up for the BaseSimpleCPU which
doesn't actually do anything in either C++ or python was not carried
forward. The CPU type still exists, but it isn't installed in the
simple CPUs.
To provide backward compatibility, each ISA implements a .py file which
matches the original .py for a CPU, and the original is renamed with a
Base prefix. The ISA specific version creates an alias with the old CPU
name which maps to the ISA specific type. This way, old scripts which
refer to, for example, AtomicSimpleCPU, will get the X86AtomicSimpleCPU
if the x86 version was compiled in, the ArmAtomicSimpleCPU on arm, etc.
Unfortunately, because of how tags on PySource and by extension SimObjects
are implemented right now, if you set the tags on two SimObjects or
PySources which have the same module path, the later will overwrite the
former whether or not they both would be included. There are some
changes in review which would revamp this and make it work like you
would expect, without this central bookkeeping which has the conflict.
Since I can't use that here, I fell back to checking TARGET_ISA to
decide whether to tell SCons about those files at all.
In the long term, this mechanism should be revamped so that these
compatibility types are only available if there is exactly one ISA
compiled into gem5. After the configs have been updated and no longer
assume they can use AtomicSimpleCPU in all cases, then these types can
be deleted.
Also, because ISAs can now either provide subclasses for a CPU or not,
the CPU_MODELS variable has been removed, meaning the non-ISA
specialized versions of those CPU models will always be included in
gem5, except when building the NULL ISA.
In the future, a more granular config mechanism will hopefully be
implemented for *all* of gem5 and not just the CPUs, and these can be
conditional again in case you only need certain models, and want to
reduce build time or binary size by excluding the others.
Change-Id: I02fc3f645c551678ede46268bbea9f66c3f6c74b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52490
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The LSQSenderState that was attached to Request was not useful.
All the fields were either a duplicate of information in the
LSQRequest or totally unused.
The LSQRequest class now inherits from Packet::SenderState and is
attached to the Packet that are sent to memory. We do not need
anymore the indirection Packet->SenderState->LSQRequest.
This helps making the code clearer as it was sometimes hard to
follow the difference between what the LSQRequest and
LSQSenserState was doing
(ex: number of outstanding requests in the memory).
Change-Id: I5b21e007e6d183c6aa79c27c1787ca56dcbc3fb0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50733
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit c417b76 changed the behaviour of addRequest(),
but did not update documentation or the HTM-related logic that used it.
Updates documentation for addRequest() in light of c417b76,
refactors request class to be idiomatic and use assigned byteEnable,
made HTM cmds pass in a correct byteEnable.
Change-Id: I7aa8c127df896e81caf915fbfea93e7b4bcc53b7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50147
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Apply the gem5 namespace to the codebase.
Some anonymous namespaces could theoretically be removed,
but since this change's main goal was to keep conflicts
at a minimum, it was decided not to modify much the
general shape of the files.
A few missing comments of the form "// namespace X" that
occurred before the newly added "} // namespace gem5"
have been added for consistency.
std out should not be included in the gem5 namespace, so
they weren't.
ProtoMessage has not been included in the gem5 namespace,
since I'm not familiar with how proto works.
Regarding the SystemC files, although they belong to gem5,
they actually perform integration between gem5 and SystemC;
therefore, it deserved its own separate namespace.
Files that are automatically generated have been included
in the gem5 namespace.
The .isa files currently are limited to a single namespace.
This limitation should be later removed to make it easier
to accomodate a better API.
Regarding the files in util, gem5:: was prepended where
suitable. Notice that this patch was tested as much as
possible given that most of these were already not
previously compiling.
Change-Id: Ia53d404ec79c46edaa98f654e23bc3b0e179fe2d
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46323
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Use O3CPU when building instead of AlphaO3CPU.
I could use some better python magic in the cpu_models.py file!
AUTHORS:
add middle initial
SConstruct:
change from AlphaO3CPU to O3CPU
src/cpu/SConscript:
edits to build O3CPU instead of AlphaO3CPU
src/cpu/cpu_models.py:
change substitution template to use proper CPU EXEC CONTEXT For O3CPU Model...
Actually, some Python expertise could be used here. The 'env' variable is not
passed to this file, so I had to parse through the ARGV to find the ISA...
src/cpu/o3/base_dyn_inst.cc:
src/cpu/o3/bpred_unit.cc:
src/cpu/o3/commit.cc:
src/cpu/o3/cpu.cc:
src/cpu/o3/cpu.hh:
src/cpu/o3/decode.cc:
src/cpu/o3/fetch.cc:
src/cpu/o3/iew.cc:
src/cpu/o3/inst_queue.cc:
src/cpu/o3/lsq.cc:
src/cpu/o3/lsq_unit.cc:
src/cpu/o3/mem_dep_unit.cc:
src/cpu/o3/rename.cc:
src/cpu/o3/rob.cc:
use isa_specific.hh
src/sim/process.cc:
only initi NextNPC if not ALPHA
src/cpu/o3/alpha/cpu.cc:
alphao3cpu impl
src/cpu/o3/alpha/cpu.hh:
move AlphaTC to it's own file
src/cpu/o3/alpha/cpu_impl.hh:
Move AlphaTC to it's own file ...
src/cpu/o3/alpha/dyn_inst.cc:
src/cpu/o3/alpha/dyn_inst.hh:
src/cpu/o3/alpha/dyn_inst_impl.hh:
include paths
src/cpu/o3/alpha/impl.hh:
include paths, set default MaxThreads to 2 instead of 4
src/cpu/o3/alpha/params.hh:
set Alpha Specific Params here
src/python/m5/objects/O3CPU.py:
add O3CPU class
src/cpu/o3/SConscript:
include isa-specific build files
src/cpu/o3/alpha/thread_context.cc:
NEW HOME of AlphaTC
src/cpu/o3/alpha/thread_context.hh:
new home of AlphaTC
src/cpu/o3/isa_specific.hh:
includes ISA specific files
src/cpu/o3/params.hh:
base o3 params
src/cpu/o3/thread_context.hh:
base o3 thread context
src/cpu/o3/thread_context_impl.hh:
base o3 thead context impl
--HG--
rename : src/cpu/o3/alpha_cpu.cc => src/cpu/o3/alpha/cpu.cc
rename : src/cpu/o3/alpha_cpu.hh => src/cpu/o3/alpha/cpu.hh
rename : src/cpu/o3/alpha_cpu_builder.cc => src/cpu/o3/alpha/cpu_builder.cc
rename : src/cpu/o3/alpha_cpu_impl.hh => src/cpu/o3/alpha/cpu_impl.hh
rename : src/cpu/o3/alpha_dyn_inst.cc => src/cpu/o3/alpha/dyn_inst.cc
rename : src/cpu/o3/alpha_dyn_inst.hh => src/cpu/o3/alpha/dyn_inst.hh
rename : src/cpu/o3/alpha_dyn_inst_impl.hh => src/cpu/o3/alpha/dyn_inst_impl.hh
rename : src/cpu/o3/alpha_impl.hh => src/cpu/o3/alpha/impl.hh
rename : src/cpu/o3/alpha_params.hh => src/cpu/o3/alpha/params.hh
rename : src/python/m5/objects/AlphaO3CPU.py => src/python/m5/objects/O3CPU.py
extra : convert_revision : d377d6417452ac337bc502f28b2fde907d6b340e
