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>
When defining a static constexpr variable in C++11, it is still
required to have a separate definition someplace, something that can
be particularly problematic in template classes. C++17 fixes this
problem by adding inline variables which don't, but in the mean time
having a static constexpr value with no backing store will, if the
compiler decides to not fold away the storage location, cause linking
errors.
This happened to me when trying to build the debug build of ARM just
now.
By turning these expressions into static inline functions, then they
no longer need definitions elsewhere, still fold away to nothing, and
are compliant with C++11 which is currently the standard gem5 expects
to be using.
Change-Id: I647d7cf4a1e8de98251ee9ef116f007e08eac1f3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24964
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
gem5 does not historically distinguish between address spaces when
interacting with gdb, and gdb doesn't really give it any address space
information to work with. To ensure we catch whatever address space
we might be in by the time we get to the interesting address, we'll set
a breakpoint in all possible address spaces simultaneously with the
expectation that we'll hit one of them.
Change-Id: I9f4b93d04914db7a3c42be6236a523d35194afda
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25268
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
Recent changes in the setupBootloader method didn't take into account
that the VExpress_GEM5_Base class does require "loc" to be passed
to the bootloader setup method:
setupBootLoader(self, cur_sys, loc, boot_loader=None)
However VExpress_GEM5_V2_Base was just passing cur_sys and boot_loader
so that the bootloader was being passed as loc and boot_loader was
passed as None (default parameter):
super(VExpress_GEM5_V2_Base, self).setupBootLoader(
cur_sys, boot_loader)
This patch is fixing this by removing loc from the VExpress_GEM5_Base
interface: the bootloader defaults (usinbg loc) are being set in the
derived classes (V1 and V2)
Change-Id: Ic4d4e4fd8d45a7af9207900287828119c3d7d56c
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25583
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
When the last event is removed from a breakpoint, then the breakpoint
itself is uninstalled from IRIS, and the list is deleted. Even though
the list has been traversed and so we don't lose track of any other
events that need to be processed, we also still need to check against
end() to see that we're done. If that now freed memory gets
overwritten, then we won't see the end and will wander right off the
end of the list into nonsense.
This change modifies the breakpoint info tracking structure to keep a
shared pointer to the event list. The pointer will still automatically
manage the list's memory so that it doesn't leak, and it won't get
deleted out from under us as we're iterating through it.
Change-Id: I5ad0f095d07f0a3a5cce9c10f03121827a674c33
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24965
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
