A Dockerfile must start with the importation of a docker base image. It
is only after this point that `LABEL` be provided. Having `LABEL` at the
top of the Dockerfiles resulted in the Docker images failing to build.
This avoids repeating the same switch construct
Change-Id: Ie16c52519b1e1f984284f2f1344a3903a0010d36
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
System(Misc) register accesses are not the only trappable instructions.
We move the exception generation logic (generateTrap) from the
MiscRegOp64 to the base ArmStaticInst
Change-Id: Ie2ba0c39790f50e3e8d504d153025d402283ec95
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This replaces hardcoded integral values with more explicit constant
names in the code allocating functional units to instructions.
This commit follows ba5886aee7 which
should have read:
"If an instruction requires a functional unit that is not present in the
model (e.g., because it is not present in the configuration), O3CPU
treats it as a 1-cycle operation.
This commit changes the behavior to make the cpu panic when this
happens. The cpu panics only if the instruction reaches the head of the
ROB, meaning it is ok to have unsupported instructions on the wrong
path.
Thanks to Chandana S. Deshpande (deshpande.s.chandana@gmail.com) for
finding the issue."
Change-Id: I5e0a37e5fb8404cb5496bd2cb0a9a5baeae3b895
Co-authored-by: Arthur perais <arthur.perais@univ-grenoble-alpes.fr>
This commit is adjusting the constructor to relax template
requirements. In this way child classes are free to provide
their own way of calculating the number of entries and the
shifting required to extract the set
Why do we need this?
Up to this patch we have been configuring the indexing policy
by setting up the cache/table size (in bytes) and the entry size.
Those parameters make a lot of sense in caching structures
where:
a) We want to configure the caching structure using
the amount of storage (in bytes) provided (e.g. 4kB of Cache)
b) the content of a single entry is addressable therefore
we need the entry size to know how many bits in the indexing
process we need to shift to extract the set
In those cases the number of cache entries is derived from the formula
num_entries = size / entry_size
The adoption of the IndexingPolicy for different kinds
of caching structures (e.g. prefetcher tables) make this
way of configuring the IP a bit quirky.
For some tables directly setting the number of entries is a far more
intuitive way of configuring the IP, instead of allocating the desired
number of entries by working things out with the formula above
Change-Id: Ic7994c129196d6ba83dc99ce397ad43393d35252
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This commit adds a test that checks that strings representing
base 10 memory sizes or base 10 memory bandwidths are correctly
converted to strings representing base 2 values.
Change-Id: Ie8cac15f06b4ceb1786484fea4e8ba2111f4e8d3
This commit refactors the base 10 to base 2 error message such
that it uses the preexisting _split_suffix function instead
of a new function based off of _split_suffix. This commit also
removes the new helper function used previously.
Change-Id: I44d9ac3d8b98bcff33d6bfea7ffbdb5009272ede
At present, if an instruction requires a functional unit that is not
present in the O3CPU config, O3CPU treats it as a 1-cycle operation that
does not consume an FU. This seems like a silent failure : if I forgot
to add a FU for a new operation type I added, then I don't want it to
silently work "for free".
The problem is that the code treats the FU allocator returning
`NoCapableFU` for a given DynInst as equivalent to the case where the
DynInst obtained an FU, with default latency of 1. This is because there
is a single if statement that checks whether the FU allocator returned
`NoFreeFU` or not, and `NoCapableFU` happens to be different. The change
is to introduce `NoNeedFU` and to panic if the FU allocator returns
`NoCapableFU`
An improvement would be to use a strongly typed enum rather than integer
constants. Thoughts ?
In addition to unit tests, I have tested this with `main.py run` and get
panics if I remove support for `IntMul` type in `O3CPU.py` in:
```
./SuiteUID-asm-riscv-rv32um-ps-mul-o3-ALL-x86_64-opt/TestUID-asm-riscv-rv32um-ps-mul-o3-ALL-x86_64-opt/simerr.txt:src/cpu/o3/inst_queue.cc:905: panic: Processor cannot execute opclass:2
./SuiteUID-asm-riscv-rv32um-ps-mulh-o3-ALL-x86_64-opt/TestUID-asm-riscv-rv32um-ps-mulh-o3-ALL-x86_64-opt/simerr.txt:src/cpu/o3/inst_queue.cc:905: panic: Processor cannot execute opclass:2
./SuiteUID-asm-riscv-rv32um-ps-mulhsu-o3-ALL-x86_64-opt/TestUID-asm-riscv-rv32um-ps-mulhsu-o3-ALL-x86_64-opt/simerr.txt:src/cpu/o3/inst_queue.cc:905: panic: Processor cannot execute opclass:2
./SuiteUID-asm-riscv-rv32um-ps-mulhu-o3-ALL-x86_64-opt/TestUID-asm-riscv-rv32um-ps-mulhu-o3-ALL-x86_64-opt/simerr.txt:src/cpu/o3/inst_queue.cc:905: panic: Processor cannot execute opclass:2
./SuiteUID-asm-riscv-rv64um-ps-mul-o3-ALL-x86_64-opt/TestUID-asm-riscv-rv64um-ps-mul-o3-ALL-x86_64-opt/simerr.txt:src/cpu/o3/inst_queue.cc:905: panic: Processor cannot execute opclass:2
./SuiteUID-asm-riscv-rv64um-ps-mulh-o3-ALL-x86_64-opt/TestUID-asm-riscv-rv64um-ps-mulh-o3-ALL-x86_64-opt/simerr.txt:src/cpu/o3/inst_queue.cc:905: panic: Processor cannot execute opclass:2
./SuiteUID-asm-riscv-rv64um-ps-mulhsu-o3-ALL-x86_64-opt/TestUID-asm-riscv-rv64um-ps-mulhsu-o3-ALL-x86_64-opt/simerr.txt:src/cpu/o3/inst_queue.cc:905: panic: Processor cannot execute opclass:2
./SuiteUID-asm-riscv-rv64um-ps-mulhu-o3-ALL-x86_64-opt/TestUID-asm-riscv-rv64um-ps-mulhu-o3-ALL-x86_64-opt/simerr.txt:src/cpu/o3/inst_queue.cc:905: panic: Processor cannot execute opclass:2
./SuiteUID-asm-riscv-rv64um-ps-mulw-o3-ALL-x86_64-opt/TestUID-asm-riscv-rv64um-ps-mulw-o3-ALL-x86_64-opt/simerr.txt:src/cpu/o3/inst_queue.cc:905: panic: Processor cannot execute opclass:2
./SuiteUID-BaseCPUProcessor-arm-hello-ALL-x86_64-opt/TestUID-BaseCPUProcessor-arm-hello-ALL-x86_64-opt/simerr.txt:src/cpu/o3/inst_queue.cc:905: panic: Processor cannot execute opclass:2
./SuiteUID-cpu_test_ArmDerivO3CPU_Bubblesort-ALL-x86_64-opt/TestUID-cpu_test_ArmDerivO3CPU_Bubblesort-ALL-x86_64-opt/simerr.txt:src/cpu/o3/inst_queue.cc:905: panic: Processor cannot execute opclass:2
./SuiteUID-cpu_test_ArmDerivO3CPU_FloatMM-ALL-x86_64-opt/TestUID-cpu_test_ArmDerivO3CPU_FloatMM-ALL-x86_64-opt/simerr.txt:src/cpu/o3/inst_queue.cc:905: panic: Processor cannot execute opclass:2
./SuiteUID-cpu_test_RiscvDerivO3CPU_Bubblesort-ALL-x86_64-opt/TestUID-cpu_test_RiscvDerivO3CPU_Bubblesort-ALL-x86_64-opt/simerr.txt:src/cpu/o3/inst_queue.cc:905: panic: Processor cannot execute opclass:2
./SuiteUID-cpu_test_RiscvDerivO3CPU_FloatMM-ALL-x86_64-opt/TestUID-cpu_test_RiscvDerivO3CPU_FloatMM-ALL-x86_64-opt/simerr.txt:src/cpu/o3/inst_queue.cc:905: panic: Processor cannot execute opclass:2
./SuiteUID-o3-cpu_1-cores_classic_DualChannelDDR3_1600_arm_boot_test_to-tick-ALL-x86_64-opt/TestUID-o3-cpu_1-cores_classic_DualChannelDDR3_1600_arm_boot_test_to-tick-ALL-x86_64-opt/simerr.txt:src/cpu/o3/inst_queue.cc:905: panic: Processor cannot execute opclass:2
./SuiteUID-o3-cpu_1-cores_classic_DualChannelDDR3_1600_riscv-boot-test_to-tick-ALL-x86_64-opt/TestUID-o3-cpu_1-cores_classic_DualChannelDDR3_1600_riscv-boot-test_to-tick-ALL-x86_64-opt/simerr.txt:src/cpu/o3/inst_queue.cc:905: panic: Processor cannot execute opclass:2
./SuiteUID-test-arm-hello32-static-o3-ALL-x86_64-opt/TestUID-test-arm-hello32-static-o3-ALL-x86_64-opt/simerr.txt:src/cpu/o3/inst_queue.cc:905: panic: Processor cannot execute opclass:2
./SuiteUID-test-arm-hello64-static-o3-ALL-x86_64-opt/TestUID-test-arm-hello64-static-o3-ALL-x86_64-opt/simerr.txt:src/cpu/o3/inst_queue.cc:905: panic: Processor cannot execute opclass:2
./SuiteUID-test-mips-hello-o3-ALL-x86_64-opt/TestUID-test-mips-hello-o3-ALL-x86_64-opt/simerr.txt:src/cpu/o3/inst_queue.cc:905: panic: Processor cannot execute opclass:2
./SuiteUID-test-riscv-hello-o3-ALL-x86_64-opt/TestUID-test-riscv-hello-o3-ALL-x86_64-opt/simerr.txt:src/cpu/o3/inst_queue.cc:905: panic: Processor cannot execute opclass:2
./SuiteUID-test-riscv-print-this-o3-ALL-x86_64-opt/TestUID-test-riscv-print-this-o3-ALL-x86_64-opt/simerr.txt:src/cpu/o3/inst_queue.cc:905: panic: Processor cannot execute opclass:2
```
Co-authored-by: Arthur perais <arthur.perais@univ-grenoble-alpes.fr>
**Note**: Erin needs to complete the commit by expanding this test to
properly test the behavior of this change.
To run the pyunit tests:
```sh
scons build/ALL/gem5.opt -j`nproc`
./build/ALL/gem5.opt tests/run_pyunit.py
```
Change-Id: I8cea0fe8b088e03e84072a000444953768bc3151
According to the pybind documentation, "When combining *args or **kwargs
with Keyword arguments you should not include py::arg tags for the
py::args and py::kwargs arguments."
In the current implementation of gem5, if you use the cxxMethod
decorator on a function that has *args or **kwargs, gem5 will
incorrectly add these variables to the pybind generated declaration.
I.e., def f(arg1, arg2, *args, **kwargs): -> .def("f", &f,
py::arg("arg1"), py::arg("arg2"), py::arg("*args"), py::arg("**kwargs"))
which is incorrect pybind code.
To fix this problem, we should ignore variables in the generator if they
are *args or **kwargs. This change skips these variables when creating
the pybind declaration.
Change-Id: I44a1e0eb0b5fc5c1e1d423ba145d456bff92c6b8
There is a compiler error with GCC 12 discussed here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115824
This Pybind code triggers the bug and was causing our compiler tests to
fail.
To fix gem5 compilation for gcc 12 these warnings/errors have been
suppressed for this code.
There is a compiler error with GCC 12 discussed here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115824
This Pybind code triggers the bug and was causing our compiler tests to
fail.
To fix gem5 compilation for gcc 12 these warnings/errors have been
suppressed for this code.
This is a copy and paste of:
https://github.com/pybind/pybind11/pull/5355
Change-Id: I9344951ef00d121ea0b609f4faa13dfe09aabb3b
This commit refactors the error message added to convert.py.
A mapping between the base 10 and base 2 suffix magnitudes
(e.g. k: ki, M: Mi, etc.) and a new function that extracts the
magnitude and numerical value have been added. Also, a warning
message has been added to the toMemoryBandwidth function in
addition to the one in toMemorySize.
Change-Id: I3ae157d13c7089d38a34a6e4c35a2b58978106d0
A bug was uncovered in that for various syscalls that used 64bit
parametres, the ABI for 32bit operating systems was passing the wrong
values to the syscalls, due to discrepancies between the target and
guest OS. This commit fixes that by replacing 64-bit types, or types
that are platform specific in size, with the exact correspondent for the
guest OS, thus producing the correct signature for the respective
syscalls. On top of this, the --param argument is added to the
starter_se script, in order to support attachment of remote debuggers.
This PR adds labels to Dockerfiles. The labels are the source
(https://github.com/gem5/gem5), a description, and the license.
Change-Id: I47ce432257641b394efef4958f1474eefe2a11c1
Co-authored-by: Harshil Patel <harshilp2107@gmail.com>
Unmap queues with queue_sel of 2 unmaps all queues while queue_sel of 3
unmaps all non-static queues. The implementation of 3 was actually
correct for 2. Static queues are queues which were mapped using a map
queues packet with a queue_type of 1 or 2.
This commit adds ability to mark a queue as static. When unmap queues
with queue_sel of 2 is sent, the existing code is now executed. With a
value of 3, we now check if the queue was marked static and do not unmap
it if marked.
Change-Id: I87d7cf78a0600c7baa516c01f42c294d3c4e90c5
Unmap queues with queue_sel of 2 unmaps all queues while queue_sel of 3
unmaps all non-static queues. The implementation of 3 was actually
correct for 2. Static queues are queues which were mapped using a map
queues packet with a queue_type of 1 or 2.
This commit adds ability to mark a queue as static. When unmap queues
with queue_sel of 2 is sent, the existing code is now executed. With a
value of 3, we now check if the queue was marked static and do not
unmap it if marked.
Change-Id: I87d7cf78a0600c7baa516c01f42c294d3c4e90c5
LT <= was previously correct while < is not. Can lead to incorrect
program execution. Related to #1366 related to #1520
Change-Id: I00b7838e920eee7c8adb508e869fdf53a9373e1f
The AssociativeCache is used by different caching agents.
This PR will allow to pass the appropriate flag to the cache so that we
can meaningfully debug
its internals. For instance, when used to model a prefetcher table, will
will pass the
HWPrefetch flag; when used to model a TLB, we will pass the TLB flag.
The Vega ISA's s_memtime instruction is used to obtain a cycle value
from the GPU. Previously, this was implemented to obtain the cycle count
when the memtime instruction reached the execute stage of the GPU
pipeline. However, from microbenchmarking we have found that this under
reports the latency for memtime instructions relative to real hardware.
Thus, we changed its behavior to go through the scalar memory pipeline
and obtain a latency value from the the SQC (L1 I$). This mirrors the
suggestion of the AMD Vega ISA manual that s_memtime should be treated
like a s_load_dwordx2.
The default latency was set based on microbenchmarking.
Change-Id: I5e251dde28c06fe1c492aea4abf9f34f05784420
Explicitly convert to float/double to fix compiler warnings that I have
turned on locally. It might make sense to make use of fplib functions to
be portable across different host float formats but something as simple
as comparison against zero should be safe.
Change-Id: I96c6ee7c5497fece11be07234ff80ff86e7555e2
Programming an event ID while counters are disabled is perfectly fine,
so we should just log this using DPRINTF instead of printing a warn()
every time it happens.
Change-Id: Ib9499857271033ef941f74a7f012d8694328eaf3
I'm not entirely sure what the mandated behaviour is according the the
ARM ARM, but I was very confused by the counters continuing to increment
with the old event even when programmed to an event ID that is not
currently supported by GEM5. Disconnecting the counter if the event is
not supported is less surprising behaviour IMO.
Change-Id: I927d9339c138dafa1484db1515c2aa09b0a9a0a9
This matches the Arm manual and the output produced by capstone. Also
avoid unnecessary spaces in vsel* instruction printing.
Change-Id: I071dd834b7104f10f6358a6b2e2895bdab64df82
We are adding two debug prints in the AssociativeCache:
1) Inserting print
2) Evicting print
Among those, the evicting one is probably the most important
This is because while the DPRINTF can be added in the
Entry::insert implementation (called during insertion),
the AssociativeCache does not reference any evict method.
Instead, the findVictim is transparently invalidating the
victim, which makes it impossible for the client code
to understand whether the victim was a valid
entry or not.
Change-Id: I4fee59cc63c6b0e14c5b02bcf3ba5f58aa21ef9f
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This will allow to print debug information for the associative
cache depending on its usage
Change-Id: Ia64e1cd7cb31fcbac27d031c38cd448ea64c5b4d
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Add declaration of HAFGRTR_EL2 registers and read/write as GPR.
Change-Id: I87570d1e87d479f4530cf2c6e05931cdc26ee361
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This commit contains the rest of the base 2 vs base 10 cache/memory
size clarifications. It also changes the warning message to use
warn(). With these changes, the warning message should now no
longer show up during a fresh compilation of gem5.
Change-Id: Ia63f841bdf045b76473437f41548fab27dc19631
This commit adds a warning message for when cache or memory sizes
will be automatically converted from metric units (e.g. kB) to
binary units (e.g. KiB).
Change-Id: I4ddf199ff2f00c78bbcb147e04bd88c496fa16ae
This commit changes files in src/python/gem5 so that memory and
cache sizes use "KiB", "MiB", and "GiB" instead of "KB", etc. This
makes the codebase more consistent, as gem5 will automatically
convert memory and cache sizes that are in metric units (KB) to
binary units (KiB).
Change-Id: If5b1e908ddcff7182b71e789229a3ba1fa6ad1f1
This PR implements #1429. It mainly achieve so with the following
changes
1) The IndexingPolicy is now a templated SimObject to make its APIs work
with different data types.
As an example, look at the getPossibleEntries, which is requiring an
Addr object whereas we want to be able to call the method with different
keys depending on the Tag
2) The AssociativeCache extracts type information from the Entry
template parameter.
This means any AssociativeCache entry will have to define the following
types:
KeyType = This is the data type used for lookups (in its simplest case,
it is Addr)
IndexingPolicy = This is the base indexing policy SimObject
As an example, the PR is also reworking the TaggedEntry to be
AssociativeCache compliant. This
ultimately allows us to remove the weird overloading of cache querying
methods with the secure flag, and to
remove the AssociativeSet which was providing such weird interface.
As mentioned in the [base, mem-cache: Rewrite TaggedEntry
code](7ee9790464)
commit, further cleanup is needed. TaggedEntry
is really a misleading name as its sole difference with the CacheEntry
(which is also tagged) is the presence of
the secure bit. A better name should be chosen.
We don't store a pointer to the indexing policy anymore.
Instead, we register a tag extractor callback when we
construct the TaggedEntry
Change-Id: I79dbc1bc5c5ce90d350e83451f513c05da9f0d61
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
We don't store a pointer to the indexing policy anymore.
Instead, we register a tag extractor callback when we
construct the CacheEntry
Change-Id: I06dc58e2f67e01f3f9bcd9f0c641505d3aec82ff
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
As detailed by a previous commit, AssociativeSet is not needed anymore.
The class is effectively the same as AssociativeCache
Change-Id: I24bfb98fbf0826c0a2ea6ede585576286f093318
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
The only difference between the TaggedEntry and the newly defined
CacheEntry is the presence of the secure flag in the first case. The
need to tag a cache entry according to the security bit required the
overloading of the matching methods in the TaggedEntry class to take
security into account (See matchTag [1]), and the persistance after
PR #745 of the AssociativeSet class which is basically identical
to its AssociativeCache superclass, only it overrides its virtual
method to match the tag according to the secure bit as well.
The introduction of the KeyType parameter in the previous commit
will smoothe the differences and help unifying the interface.
Rather than overloading and overriding to account for a different
signature, we embody the difference in the KeyType class. A
CacheEntry will match with KeyType = Addr,
whereas a TaggedEntry will use the following lookup type proposed in this
patch:
struct KeyType {
Addr address;
bool secure;
}
This patch is partly reverting the changes in #745 which were
reimplementing TaggedEntry on top of the CacheEntry. Instead
we keep them separate as the plan is to allow different
entry types with templatization rather than polymorphism.
As a final note, I believe a separate commit will have to
change the naming of our entries; the CacheEntry should
probably be renamed into TaggedEntry and the current TaggedEntry
into something that reflect the presence of the security bit
alongside the traditional address tag
[1]: https://github.com/gem5/gem5/blob/stable/\
src/mem/cache/tags/tagged_entry.hh#L81
Change-Id: Ifc104c8d0c1d64509f612d87b80d442e0764f7ca
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
As long as the AssociativeCache Entry parameter satisfies the
interface it should be fine. We enforce the bare minimum of having
a replaceable entry.
Doing otherwise will restrict our capability to have a generic cache
with generic tags
Change-Id: I23e32b7540fea6b6e5894aca3d91538e81214932
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
The KeyType data type is the type of the lookup and the cache extracts
it from the Entry template parameter
Change-Id: I147d7c2503abc11becfeebe6336e7f90989ad4e8
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This commit is making the AssociativeCache indexing policy
a type extracted from the Entry template parameter
Change-Id: Ic9fb6ccb1b3549aaa250901e91ae3c300b92103e
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Exposing the tag of a cache entry through the associative
cache APIs makes it hard to generalize the cache for
structured tags. Ultimately the tag should be a property
of the cache entry and any tag extraction logic (if needed)
should reside there. In this we can reuse the associative
cache for different Entry params, each one bearing a different
representation of a tag
Change-Id: I51b4526be64683614e01d763b1656e5be23a611b
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Some compilers (gcc version 12.3.0) will start complaining when perfect
forwarding the StrideEntry argument constructed with an extra parameter
(see later patches).
Using a pointer seems to fix the gcc bug.
The commit is also changing the signature of findTable and allocateContext
so that a reference rather than a pointer is return. In this way we don't
deal with the hack of returning a raw ptr from a unique_ptr
Change-Id: Idd451208aae80bbfae76110c859e93084bcb2635
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
