The only difference was whether the the atomic op functor was accepted
as an argument. If it wasn't, setVirt would be called without an op
functor argument where it will default to nullptr.
This change deletes the constructor which doesn't take an atomic op
functor and in the other defaults the functor to nullptr. Functionally
nothing changes, but the code is now simpler.
Change-Id: Iff06543b1046594df297344e16961ee9d0f0a373
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26231
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
As described in the Jira issue, this replaces the implementation of
isPowerOf2() and power(). It also revamps floorLog2 so that there only
needs to be one implementation and no assumptions about how big certain
types are.
The way power() used to work was to raise a number n to an exponent e
by multiplying n times itself e times. As a warning in this function
explains, this can be quite slow for large e. A much more efficient
way to raise a number to an exponent is to square n over and over, and
to multiply in the current square if that bit of e is set.
n ^ 15 = (n^1) * (n^2) * (n^4) * (n^8)
n^8 = (n^4)^2
n^4 = (n^2)^2
n^2 = n^2
n^1 = n
So that takes 6 multiplications, n^2, (n^2)^2, (n^4)^2, and then each
multipy to compute the final result, instead of 14.
The difference is more pronounced for larger exponents, although you'd
quickly start to overflow a uint64_t.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-140
Change-Id: I0ae05aeba1b5882d2a616613b1679e6206b4cbfe
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26164
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These are only used in these two files, one each, and pass one dummy
argument with a default value and one extra argument with an actual
value compared to the more common constructors.
Instead, switch to constructors without those two arguments and set the
one extra value explicitly after construction.
The constructor will likely be inlined, and merged with this additional
assignment.
Change-Id: I75ca539d5ca95b57b4f4322ffa050af2031544dd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26229
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
The new local access mechanism installs a callback in the request which
implements what the mmapped IPR was doing. That avoids having to have
stubs in ISAs that don't have mmapped IPRs, avoids having to encode
what to do to communicate from the TLB and the mmapped IPR functions,
and gets rid of another global ISA interface function and header files.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: I772c2ae2ca3830a4486919ce9804560c0f2d596a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23188
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
pybind internally uses a construct which initializes an array of bools
as a way to run a function on each member of a parameter pack. It then
discards the array since it was just trying to run the function. This
triggers a warning in clang 11 called unused-value which breaks the
build.
This change adds some pragmas to the pybind11.h header which disable
that warning while in pybind11 which is less intrusive than trying to
fix the false positive warning, and better than disabling the warning
universally. Since g++ and clang++ will complain if they see this
pragma guarded by the other's name, these pragmas are also surrounded
by ifdefs which should make them only visible to clang.
Change-Id: Ie9b5c65e8cadc8b96fbc1bd7971bed4a61c4340d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25228
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
This patch fixes the AArch32-AArch64 interprocessing issue introduced in
3d15150d cpu, arch, arch-arm: Wire unused VecElem code in the O3 model.
When O3CPU switches vector renaming mode, architectural-physical mapping
and physical free list are switched in the following way so that content
of vectors has no change from software view:
Case 1. Full mode -> Elem mode (AArch64 -> AArch32):
1.1. Split vector-vector mapping into element-element mapping.
1.2. Split vectors in free list into elements.
Case 2. Elem mode -> Full mode (AArch32 -> AArch64):
2.1. Move content of all N*M mapped physical elements to first N*M
physical elements in architectural order (N = number of
architectural vectors, M = number of elements per vector).
2.2. Map N architectural vectors to first N physical vectors (i.e.
initial mapping in full mode).
2.3. Place remaining physical vectors in free list (i.e. initial free
list in full mode).
Previous gem5 revision misses step 2.2 when AArch32->AArch64 switch.
The wrong mapping will lead to the situation in which a physical vector
is assigned twice to a same architectural vector without being freed.
Once this occurs, the physical vector will not be freed anymore, since
it is treated as a special register (e.g. zero or misc) by O3CPU's
renaming logic. Eventually O3CPU will either stall forever when all
physical vectors get stuck, or trigger the panic condition "The free
list has lost vector registers" when AArch64->AArch32 switch. This patch
adds the missing step and fixes the issue.
Change-Id: I32233635c28763260bcbb776b52ed198a9abace9
Signed-off-by: Hsuan Hsu <hsuan.hsu@mediatek.com>
Signed-off-by: Howard Wang <Howard.Wang@mediatek.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25743
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently the System class has a mechanism to wait for a GDB connection
for each CPU which has requested it through one of its parameters.
Unfortunately, not every thread context/CPU will be ready for GDB at
that point, particularly considering that in an FS simulation the
kernel won't have been read so there will be no symbols, none of the
registers or the entry point will have been set.
Also in the fast models, the CPUs haven't had a chance to initialize
themselves enough by that point to respond to the API calls which are
used to implement GDB support.
Change-Id: If27cb3e0259a1f67599ab0493695b2f8af640d8e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24963
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Change the guest ABI for x86 pseudo instructions to explictly write rax.
This is required because for some reason, the KVM CPU overwrites rax
after the KVM MMIO sets the value.
Note: This is hacky. It will only work for the current implementations
of x86 m5 ops which have their return value in RAX. A comment is added
to the m5ops file to make this clear.
Change-Id: I9466bf050b26db3650cfe3d23008e0f77fda8bc0
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25664
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
The _on_chip_memory member function is utilised at RealView level, but
it does not provide a default implementation. This assumes all platforms
extending RealView have on-chip memory. This patch provides a default
implementation for safeness.
Change-Id: Iaaa2bee7a85653ee97bfa95b50047eb350a88b58
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25643
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
