The ROCr runtime uses a combination of HSA signal timestamps and
hardware MMIOs to calculate profiling times. At the beginning of an
application a timestamp is read from the GPU using MMIOs. The clock
MMIOs reside in the GFX MMIO region, so a new AMDGPUGfx class is added
to handle these MMIOs.
The timestamp value is expected to be in nanoseconds, so we simply use
the gem5 tick converted to ns.
Change-Id: I7d1cba40d5042a7f7a81fd4d132402dc11b71bd4
The AMD specific HSA signal contains start/end timestamps for dispatch
packet completion signals. These are current always zero. These
timestamp values are used for profiling in the ROCr runtime.
Unfortunately, the GpuAgent::TranslateTime method in ROCr does not check
for zero values before dividing, causing applications that use profiling
to crash with SIGFPE. Profiling is used via hipEvents in the HACC
application, so these should be supported in gem5.
In order to handle writing the timestamp values, we need to DMA the
values to memory before writing the completion signal. This changes the
flow of the async completion signal write to be (1) read mailbox pointer
(2) if valid, write the mailbox data, other skip to 4 (3) write mailbox
data if pointer is valid (4) write timestamp values (5) write completion
signal. The application will process the timestamp data as soon as the
completion signal is received, so we need to ordering to ensure the DMA
for timestamps was completed.
HACC now runs to completion on GPUFS and has the same output was
hardware.
Change-Id: I09877cdff901d1402140f2c3bafea7605fa6554e
Added a new feature to CHI protocol (in collaboration with @tiagormk).
Here is the Jira Ticket
[https://gem5.atlassian.net/browse/GEM5-1326](https://gem5.atlassian.net/browse/GEM5-1326
). As described in CHI specs, far atomic transactions enable remote
execution of Atomic Memory Operations. This pull request incorporates
several changes:
* Fix Arm ISA definition of Swap instructions. These instructions should
return an operand, so their ISA definition should be Return Operation.
* Enable AMOs in Ruby Mem Test to verify that AMOs work
* Enable near and far AMO in the Cache Controler of CHI
Three configuration parameters have been used to tune this behavior:
* policy_type: sets the atomic policy to one of the described in [our
paper](https://dl.acm.org/doi/10.1145/3579371.3589065)
* atomic_op_latency: simulates the AMO ALU operation latency
* comp_anr: configures the Atomic No return transaction to split
CompDBIDResp into two different messages DBIDResp and Comp
Previously, the L1, L2 number of banks and L2 latencies were not
configurable through command line arguments. This commit adds support to
configure them through the arguments '--tcp-num-banks' for number of
banks in L1, '--tcc-num-banks' for number of banks in L2, and
'--tcc-tag-access-latency', and '--tcc-data-access-latency'
Change-Id: Ie3b713ead16865fd7120e2d809ebfa56b69bc4a1
ROCm supports dynamically allocating scratch space, which resides in
framebuffer memory, to reduce the amount of memory allocated for kernels
that have not yet launched. The size of the scratch space allocated is
located in task->amdQueue.compute_tmpring_size_wavesize. This size is in
kilobytes. The AQL task contains the number of bytes requested *per work
item*, however we currently check if there is enough tmpring space by
comparing a single work item. This should instead check the size *per
wavefront*.
This causes problems in applications where multiple kernels use dynamic
scratch allocation and a later kernel requires more space than the
earlier kernel. The only application being tested that does this is
LULESH. This was resulting in the scratch space being too small,
resulting in workgroups clobbering each other's private memory leading
to some nasty bugs. It is fixed by this patch as task->amdQueue will be
re-read from the host and will contain the updated tmpring size. After
this there is enough scratch space and LULESH makes forward progress.
Introduce far atomic operations in CHI protocol.
Three configuration parameters have been used to tune this behavior:
policy_type: sets the atomic policy to one of the described in our paper
atomic_op_latency: simulates the AMO ALU operation latency
comp_anr: configures the Atomic No return transaction to split
CompDBIDResp into two different messages DBIDResp and Comp
Change-Id: I087afad9ad9fcb9df42d72893c9e32ad5a5eb478
Swap instructions are configured as non returning AMO operations. This is wrong because they
return the previous value stored in the target memory position
Change-Id: I84d75a571a8eaeaee0dbfac344f7b34c72b47d53
This introduces the changes necessary for clang-15 and clang-16 to run
within gem5, and adds them to the compiler tests.
This also updates the dockerfiles for ubuntu 22.04 to include the steps
necessary to compile clang-15 and clang-16.
ROCm supports dynamically allocating scratch space, which resides in
framebuffer memory, to reduce the amount of memory allocated for kernels
that have not yet launched. The size of the scratch space allocated is
located in task->amdQueue.compute_tmpring_size_wavesize. This size is in
kilobytes. The AQL task contains the number of bytes requested *per work
item*, however we currently check if there is enough tmpring space by
comparing a single work item. This should instead check the size *per
wavefront*.
This causes problems in applications where multiple kernels use dynamic
scratch allocation and a later kernel requires more space than the
earlier kernel. The only application being tested that does this is
LULESH. This was resulting in the scratch space being too small,
resulting in workgroups clobbering each other's private memory leading
to some nasty bugs. It is fixed by this patch as task->amdQueue will be
re-read from the host and will contain the updated tmpring size. After
this there is enough scratch space and LULESH makes forward progress.
Change-Id: Ie9e0f92bb98fd3c3d6c2da3db9ee65352f9ae070
Add the instruction size of a static instruction. x86 and arm decoders
add now the instruction size to the macro instruction. However, microops
are still handled by the fetch stage which is not nice.
Furthermore, we add a set method to the PC state. It allows setting a PC
state to acertain address.
Both methods are required for the decoupled front-end.
Change-Id: I311fe3f637e867c42dee7781f5373ea2e69e2072
Previously, the L1, L2 number of banks and L2 latencies were not
configurable through command line arguments. This commit adds support to
configure them through the arguments '--tcp-num-banks' for number of
banks in L1, '--tcc-num-banks' for number of banks in L2, and
'--tcc-tag-access-latency', and '--tcc-data-access-latency'
Change-Id: Ie3b713ead16865fd7120e2d809ebfa56b69bc4a1
I believe the point of this binary was to allow people to use the m5
objects without the entire gem5 binary. However, without adding the
importer call, this did not work. Unfortunately, with the importer call
there is a circular dependence on the original gem5py.cc file.
Therefore, this change creates a new file that has the importer call.
Now, with the `gem5py_m5` binary you can run python code that references
modules in `src/python`. Note that `_m5` is not available, so anything
that depends on the gem5 SimObjects' implementation will not work.
However, this can still be useful for things like getting Resources,
processing stats, etc.
Adds the instruction size to all static instruction. x86, arm
and RISC-V decoders add the instruction size to every decoded
macro instruction. As microops should reflect the size of the
their parent macroop the set method is overwritten to pass the
size to all microops.
Furthermore, we add a set method to the PC state. It allows
setting a PC state to a certain address.
Both methods are required for the decoupled front-end.
Change-Id: I311fe3f637e867c42dee7781f5373ea2e69e2072
Signed-off-by: David Schall <david.schall@ed.ac.uk>
* Removes `+` symbol accidently left in (this broke building).
* Removes `ARG` thus making the Docker exclusively for clang-16.
* Adds "llvm.sh" to the repo. This stops us being dependent on the url
download. The script is under the apache license therefore compatible.
* Merges several `apt install` commands into one.
Change-Id: Iaf411656aac83f67f5395b20efd96ecc1eabb263
The L3 cache did not work due to argument type mismatch in the call to
the constructor `DMAController`. The second argument is expecting a
`RubySystem` type but the code passes in a `cache_line_size` variable.
After I change the second argument to `self.ruby_system` everything
works.
There are two overloaded-virtual issues reported by g++13.
1. Copy assignment and move assignment overload is hidden in the derived
class
[ CXX] src/mem/cache/replacement_policies/weighted_lru_rp.cc ->
ALL/mem/cache/replacement_policies/weighted_lru_rp.o
In file included from src/mem/cache/base.hh:61,
from src/mem/cache/base.cc:46:
src/mem/cache/cache_blk.hh:172:5: error: ‘virtual gem5::CacheBlk&
gem5::CacheBlk::operator=(gem5::CacheBlk&&)’ was hidden
[-Werror=overloaded-virtual=]
172 | operator=(CacheBlk&& other)
| ^~~~~~~~
src/mem/cache/cache_blk.hh:518:19: note: by ‘gem5::TempCacheBlk&
gem5::TempCacheBlk::operator=(const gem5::TempCacheBlk&)’
518 | TempCacheBlk& operator=(const TempCacheBlk&) = delete;
| ^~~~~~~~
In this case, we can exiplict using parent operator= to keep the
function overload.
2. Intended overload hidden in SystemC is reported as error.
In file included from
src/systemc/ext/tlm_utils/simple_initiator_socket.h:24,
from src/systemc/tlm_bridge/gem5_to_tlm.hh:72,
from build/ALL/python/_m5/param_Gem5ToTlmBridge256.cc:17:
src/systemc/ext/tlm_utils/../tlm_core/2/sockets/initiator_socket.hh: In
instantiation of ‘class tlm::tlm_base_initiator_socket<256,
tlm::tlm_fw_transport_if<>, tlm::tlm_bw_transport_if<>, 1,
sc_core::SC_ONE_OR_MORE_BOUND>’:
src/systemc/ext/tlm_utils/../tlm_core/2/sockets/initiator_socket.hh:185:7:
required from ‘class tlm::tlm_initiator_socket<256,
tlm::tlm_base_protocol_types, 1, sc_core::SC_ONE_OR_MORE_BOUND>’
src/systemc/ext/tlm_utils/simple_initiator_socket.h:37:7: required from
‘class
tlm_utils::simple_initiator_socket_b<sc_gem5::Gem5ToTlmBridge<256>, 256,
tlm::tlm_base_protocol_types, sc_core::SC_ONE_OR_MORE_BOUND>’
src/systemc/ext/tlm_utils/simple_initiator_socket.h:156:7: required from
‘class tlm_utils::simple_initiator_socket<sc_gem5::Gem5ToTlmBridge<256>,
256, tlm::tlm_base_protocol_types>’
src/systemc/tlm_bridge/gem5_to_tlm.hh:147:46: required from ‘class
sc_gem5::Gem5ToTlmBridge<256>’
/usr/include/c++/13/type_traits:1411:38: required from ‘struct
std::is_base_of<sc_gem5::Gem5ToTlmBridgeBase,
sc_gem5::Gem5ToTlmBridge<256> >’
ext/pybind11/include/pybind11/detail/../detail/common.h:880:59: required
from ‘struct pybind11::class_<sc_gem5::Gem5ToTlmBridge<256>,
sc_gem5::Gem5ToTlmBridgeBase,
std::unique_ptr<sc_gem5::Gem5ToTlmBridge<256>, pybind11::nodelete>
>::is_valid_class_option<sc_gem5::Gem5ToTlmBridgeBase>’
ext/pybind11/include/pybind11/detail/../detail/common.h:719:35: required
by substitution of ‘template<class ... Ts> using
pybind11::detail::all_of = pybind11::detail::bool_constant<(Ts::value &&
...)> [with Ts = {pybind11::class_<sc_gem5::Gem5ToTlmBridge<256>,
sc_gem5::Gem5ToTlmBridgeBase,
std::unique_ptr<sc_gem5::Gem5ToTlmBridge<256>, pybind11::nodelete>
>::is_valid_class_option<sc_gem5::Gem5ToTlmBridgeBase>,
pybind11::class_<sc_gem5::Gem5ToTlmBridge<256>,
sc_gem5::Gem5ToTlmBridgeBase,
std::unique_ptr<sc_gem5::Gem5ToTlmBridge<256>, pybind11::nodelete>
>::is_valid_class_option<std::unique_ptr<sc_gem5::Gem5ToTlmBridge<256>,
pybind11::nodelete> >}]’
ext/pybind11/include/pybind11/pybind11.h:1506:70: required from ‘class
pybind11::class_<sc_gem5::Gem5ToTlmBridge<256>,
sc_gem5::Gem5ToTlmBridgeBase,
std::unique_ptr<sc_gem5::Gem5ToTlmBridge<256>, pybind11::nodelete> >’
build/ALL/python/_m5/param_Gem5ToTlmBridge256.cc:34:179: required from
here
src/systemc/ext/tlm_utils/../core/sc_port.hh:125:18: error: ‘void
sc_core::sc_port_b<IF>::bind(sc_core::sc_port_b<IF>&) [with IF =
tlm::tlm_fw_transport_if<>]’ was hidden [-Werror=overloaded-virtual=]
125 | virtual void bind(sc_port_b<IF> &p) { sc_port_base::bind(p); }
| ^~~~
In file included from
src/systemc/ext/tlm_utils/simple_initiator_socket.h:27:
src/systemc/ext/tlm_utils/../tlm_core/2/sockets/initiator_socket.hh:133:18:
note: by ‘tlm::tlm_base_initiator_socket<256,
tlm::tlm_fw_transport_if<>, tlm::tlm_bw_transport_if<>, 1,
sc_core::SC_ONE_OR_MORE_BOUND>::bind’
133 | virtual void bind(bw_interface_type &ifs) {
(get_base_export())(ifs); }
| ^~~~
src/systemc/ext/tlm_utils/../core/sc_port.hh:124:18: error: ‘void
sc_core::sc_port_b<IF>::bind(IF&) [with IF =
tlm::tlm_fw_transport_if<>]’ was hidden [-Werror=overloaded-virtual=]
124 | virtual void bind(IF &i) { sc_port_base::bind(i); }
| ^~~~
src/systemc/ext/tlm_utils/../tlm_core/2/sockets/initiator_socket.hh:133:18:
note: by ‘tlm::tlm_base_initiator_socket<256,
tlm::tlm_fw_transport_if<>, tlm::tlm_bw_transport_if<>, 1,
sc_core::SC_ONE_OR_MORE_BOUND>::bind’
133 | virtual void bind(bw_interface_type &ifs) {
(get_base_export())(ifs); }
| ^~~~
From the code comment, it's intended in SystemC header.
// The overloaded virtual is intended in SystemC, so we'll disable the
warning. // Please check section 9.3 of SystemC 2.3.1 release note for
more details.
The issue is we should move the skip to the base class.
This patch introduces a new category called "suite".
A suite is a collection of workloads.
Each workload in a SuiteResource has a tag that can be narrowed down
through the function with_input_group.
Also, the set of input groups can be seen through list_input_groups.
Added unit tests to test all functions of SuiteResource class.
Change-Id: Iddda5c898b32b7cd874987dbe694ac09aa231f08
Co-authored-by: Kunal Pai <kunpai@ucdavis.edu>
This problem is similar to the problem described in [1]. This problem
produces symptoms as described in [2].
In short, the Linux kernel relies on the CSR_STATUS's FS bits to decide
whether to save the floating point registers. If the FS bits are set to
DIRTY, the floating point registers will be saved during context
switching / task switching.
Currently, with the patch in [1], we only change the FS bits upon every
floating arithmetic instruction. However, since floating load
instructions also mutate the state of floating point registers, the FS
bits should be updated to DIRTY.
The problem in [2] arose when the program populates the content of one
floating register to an array by repeatedly using `fld fa5, EA`. A
context switch occured upon a page fault, and while handling that page
fault, the kernel might have to handle an interrupt. This caused the
kernel to task switch between handling page fault and handling
interrupt. This caused __switch_to() to be called, which will save the
floating point registers only if the SD (indirectly set by FS) bits are
set to DIRTY, while restoring the floating point registers to the
switch-to task [3]. This caused the floating point registers to be
zeroed out when it was restored as it was never saved before.
[1] https://gem5-review.googlesource.com/c/public/gem5/+/65272
[2] https://github.com/gem5/gem5/issues/349
[3]
https://github.com/torvalds/linux/blob/v6.5/arch/riscv/include/asm/switch_to.h#L56
This updates the dockerfiles for ubuntu 22.04 to include the
steps necessary to compile clang-15 and clang-16.
Change-Id: I2bba6393ab93a6ce05a2c3ce31f3bbc71bcdca7c
This problem is similar to the problem described in [1].
This problem produces symptoms as described in [2].
In short, the Linux kernel relies on the CSR_STATUS's FS bits
to decide whether to save the floating point registers. If
the FS bits are set to DIRTY, the floating point registers will
be saved during context switching / task switching.
Currently, with the patch in [1], we only change the FS bits
upon every floating arithmetic instruction. However, since
floating load instructions also mutate the state of floating
point registers, the FS bits should be updated to DIRTY.
The problem in [2] arose when the program populates the content
of one floating register to an array by repeatedly using
`fld fa5, EA`. A context switch occured upon a page fault, and
while handling that page fault, the kernel might have to handle
an interrupt. This caused the kernel to task switch between
handling page fault and handling interrupt. This caused
__switch_to() to be called, which will save the floating point
registers only if the SD (indirectly set by FS) bits are set to
DIRTY, while restoring the floating point registers to the
switch-to task [3]. This caused the floating point registers to
be zeroed out when it was restored as it was never saved before.
[1] https://gem5-review.googlesource.com/c/public/gem5/+/65272
[2] https://github.com/gem5/gem5/issues/349
[3] https://github.com/torvalds/linux/blob/v6.5/arch/riscv/include/asm/switch_to.h#L56
Change-Id: Ia5656da5a589a8e29fb699d2ee12885b8f3fa2d2
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
I believe the point of this binary was to allow people to use the m5
objects without the entire gem5 binary. However, without adding the
importer call, this did not work. Unfortunately, with the importer call
there is a circular dependence on the original gem5py.cc file.
Therefore, this change creates a new file that has the importer call.
Now, with the `gem5py_m5` binary you can run python code that references
modules in `src/python`. Note that `_m5` is not available, so anything
that depends on the gem5 SimObjects' implementation will not work.
However, thic can still be useful for things like getting Resources,
processing stats, etc.
Change-Id: I5c0e5d1a669fe5ce491458df916f2049c81292eb
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
By default, the `--stderr-file` and `--stdout-file` arguments were
directing the simulator to output files named "simerr" and "simout"
respectively if an output redirect was requested.
A small annoyance is these files lack an extension meaning programs
refuse to open them, or don't do so withou additional effort. On many
systems they are assumed to scripts.
This patch adds the `.txt` extension to both, thus clearly indicating to
other programs these are text files and can be opened and read as such.
Currently we drop the insertion of a whole symbol table if the name of
one symbol already exists in the base table. Having similar symbols
across different binaries is common.
This change adds a warning and recommends a fix instead of silently
dropping the table.
This PR utilizes GitHub Action's matrix's to automatically distribute
the CI testlib gem5 build and test jobs across available GitHub Action
Runners.
The CI tests (the `quick` testlib tests, i.e. those run with `./main.py
run`) are distributed across the runners on a per directory basis ---
all directories under "tests/gem5" are run as their own jobs.
The necessary gem5 builds for each workflow are now automatically
inferred via the introduction of `./main.py list`'s `--build-targets`
flag which returns the gem5 build target for a given test or collection
of tests. E.g., `./main.py list --build-targets` will return the build
targets for all the `quick` testlib tests and `./main.py list
--build-target --uid=<id>` will return the build targets the test suite
`<id>` requires.
Moving from monolithic jobs to fine-grained ones will make the locaiton
of test failures more obvious. Each job has it's own artifact containing
"test/testing-results" for the tests run in that job. In addition,
maintenance of these files should become less burdensome due to less
hardcoding.
As discussed here, [1], O3CPU counts getWritableRegOperand() as a reg
read, while SimpleCPU variants count getWriableRegOperand() as a reg
write.
This patch fixes this inconsistency. Here, I assume that if
getWritableRegOperand() is used, setReg() will not be used again to
write to the destination register.
[1] https://github.com/gem5/gem5/pull/341
The auxv platform string was not copied to the same location that was
pointed to by the value of AT_PLATFORM; instead, it was copied over the
auxv random buffer. This patch fixes this by copying the auxv platform
string to the right offset in the initial program stack.
GitHub issue: https://github.com/gem5/gem5/issues/346
The popx87 micro-op did not in fact pop the st(0) floating-point
register off the stack; it acted as a no-op. This patch fixes the bug by
passing the spm=1 argument to PopX87's superclass to indicate the
floating-point stack pointer should be incremented.
GitHub issue: https://github.com/gem5/gem5/issues/344
- Added mulitline string for print message
- Added get_category_name method instead of having category as variable
Change-Id: I51e0e14a70e802453c21070711b200bc47994ba3
This introduces the changes necessary for clang-15 and clang-16
to run within gem5, and adds them to the compiler tests.
Change-Id: If809eae1bd8c366b4d62476891feff0625bdf210
There are two overloaded-virtual issues reported by g++13.
1. Copy assignment and move assignment overload is hidden in the derived
class
[ CXX] src/mem/cache/replacement_policies/weighted_lru_rp.cc -> ALL/mem/cache/replacement_policies/weighted_lru_rp.o
In file included from src/mem/cache/base.hh:61,
from src/mem/cache/base.cc:46:
src/mem/cache/cache_blk.hh:172:5: error: ‘virtual gem5::CacheBlk& gem5::CacheBlk::operator=(gem5::CacheBlk&&)’ was hidden [-Werror=overloaded-virtual=]
172 | operator=(CacheBlk&& other)
| ^~~~~~~~
src/mem/cache/cache_blk.hh:518:19: note: by ‘gem5::TempCacheBlk& gem5::TempCacheBlk::operator=(const gem5::TempCacheBlk&)’
518 | TempCacheBlk& operator=(const TempCacheBlk&) = delete;
| ^~~~~~~~
In this case, we can exiplict using parent operator= to keep the
function overload.
2. Intended overload hidden in SystemC is reported as error.
In file included from src/systemc/ext/tlm_utils/simple_initiator_socket.h:24,
from src/systemc/tlm_bridge/gem5_to_tlm.hh:72,
from build/ALL/python/_m5/param_Gem5ToTlmBridge256.cc:17:
src/systemc/ext/tlm_utils/../tlm_core/2/sockets/initiator_socket.hh: In instantiation of ‘class tlm::tlm_base_initiator_socket<256, tlm::tlm_fw_transport_if<>, tlm::tlm_bw_transport_if<>, 1, sc_core::SC_ONE_OR_MORE_BOUND>’:
src/systemc/ext/tlm_utils/../tlm_core/2/sockets/initiator_socket.hh:185:7: required from ‘class tlm::tlm_initiator_socket<256, tlm::tlm_base_protocol_types, 1, sc_core::SC_ONE_OR_MORE_BOUND>’
src/systemc/ext/tlm_utils/simple_initiator_socket.h:37:7: required from ‘class tlm_utils::simple_initiator_socket_b<sc_gem5::Gem5ToTlmBridge<256>, 256, tlm::tlm_base_protocol_types, sc_core::SC_ONE_OR_MORE_BOUND>’
src/systemc/ext/tlm_utils/simple_initiator_socket.h:156:7: required from ‘class tlm_utils::simple_initiator_socket<sc_gem5::Gem5ToTlmBridge<256>, 256, tlm::tlm_base_protocol_types>’
src/systemc/tlm_bridge/gem5_to_tlm.hh:147:46: required from ‘class sc_gem5::Gem5ToTlmBridge<256>’
/usr/include/c++/13/type_traits:1411:38: required from ‘struct std::is_base_of<sc_gem5::Gem5ToTlmBridgeBase, sc_gem5::Gem5ToTlmBridge<256> >’
ext/pybind11/include/pybind11/detail/../detail/common.h:880:59: required from ‘struct pybind11::class_<sc_gem5::Gem5ToTlmBridge<256>, sc_gem5::Gem5ToTlmBridgeBase, std::unique_ptr<sc_gem5::Gem5ToTlmBridge<256>, pybind11::nodelete> >::is_valid_class_option<sc_gem5::Gem5ToTlmBridgeBase>’
ext/pybind11/include/pybind11/detail/../detail/common.h:719:35: required by substitution of ‘template<class ... Ts> using pybind11::detail::all_of = pybind11::detail::bool_constant<(Ts::value && ...)> [with Ts = {pybind11::class_<sc_gem5::Gem5ToTlmBridge<256>, sc_gem5::Gem5ToTlmBridgeBase, std::unique_ptr<sc_gem5::Gem5ToTlmBridge<256>, pybind11::nodelete> >::is_valid_class_option<sc_gem5::Gem5ToTlmBridgeBase>, pybind11::class_<sc_gem5::Gem5ToTlmBridge<256>, sc_gem5::Gem5ToTlmBridgeBase, std::unique_ptr<sc_gem5::Gem5ToTlmBridge<256>, pybind11::nodelete> >::is_valid_class_option<std::unique_ptr<sc_gem5::Gem5ToTlmBridge<256>, pybind11::nodelete> >}]’
ext/pybind11/include/pybind11/pybind11.h:1506:70: required from ‘class pybind11::class_<sc_gem5::Gem5ToTlmBridge<256>, sc_gem5::Gem5ToTlmBridgeBase, std::unique_ptr<sc_gem5::Gem5ToTlmBridge<256>, pybind11::nodelete> >’
build/ALL/python/_m5/param_Gem5ToTlmBridge256.cc:34:179: required from here
src/systemc/ext/tlm_utils/../core/sc_port.hh:125:18: error: ‘void sc_core::sc_port_b<IF>::bind(sc_core::sc_port_b<IF>&) [with IF = tlm::tlm_fw_transport_if<>]’ was hidden [-Werror=overloaded-virtual=]
125 | virtual void bind(sc_port_b<IF> &p) { sc_port_base::bind(p); }
| ^~~~
In file included from src/systemc/ext/tlm_utils/simple_initiator_socket.h:27:
src/systemc/ext/tlm_utils/../tlm_core/2/sockets/initiator_socket.hh:133:18: note: by ‘tlm::tlm_base_initiator_socket<256, tlm::tlm_fw_transport_if<>, tlm::tlm_bw_transport_if<>, 1, sc_core::SC_ONE_OR_MORE_BOUND>::bind’
133 | virtual void bind(bw_interface_type &ifs) { (get_base_export())(ifs); }
| ^~~~
src/systemc/ext/tlm_utils/../core/sc_port.hh:124:18: error: ‘void sc_core::sc_port_b<IF>::bind(IF&) [with IF = tlm::tlm_fw_transport_if<>]’ was hidden [-Werror=overloaded-virtual=]
124 | virtual void bind(IF &i) { sc_port_base::bind(i); }
| ^~~~
src/systemc/ext/tlm_utils/../tlm_core/2/sockets/initiator_socket.hh:133:18: note: by ‘tlm::tlm_base_initiator_socket<256, tlm::tlm_fw_transport_if<>, tlm::tlm_bw_transport_if<>, 1, sc_core::SC_ONE_OR_MORE_BOUND>::bind’
133 | virtual void bind(bw_interface_type &ifs) { (get_base_export())(ifs); }
| ^~~~
From the code comment, it's intended in SystemC header.
// The overloaded virtual is intended in SystemC, so we'll disable the warning.
// Please check section 9.3 of SystemC 2.3.1 release note for more details.
The issue is we should move the skip to the base class.
Change-Id: I6683919e594ffe1fb3b87ccca1602bffdb788e7d
Adds a new probe listener template which can be used to instantiate with
a lambda function that is called by notify(). It is similar to
ProbeListenerArg with class but provides more flexibility. I.e. the can
be another object than the one instantiating the lambda which allows to
listen to any object. Furthermore additional parameters can be passed in
easily.
Change-Id: Iba451357182caf25097b9ae201cd5c647aff3a4f
With this PR our CHI implementation starts making use of the txnid and
DBID identifiers.
Note: we were already making use of the txnId for DVM messages to convey
the DVM address. This is still the case.
In the future we should realign the DVM logic so that the txnId is
solely used as a transaction identifier.
Current we drop the insertion of a whole symbol table if the name
of one symbol already exists in the base table. Having similar
symbols across different binaries is very common.
This change adds a warning and recommends a fix instead of silently
dropping the table. This is useful for debugging when there are two
or more workloads, e.g. bootloader + kernel, are added separately.
Change-Id: I9e4cf06037cd70926fb5cee3c4dab464daf0912e
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
As discussed here, [1], O3CPU counts getWritableRegOperand() as a
reg read, while SimpleCPU variants count getWriableRegOperand()
as a reg write.
This patch fixes this inconsistency. Here, I assume that if
getWritableRegOperand() is used, setReg() will not be used again
to write to the destination register.
[1] https://github.com/gem5/gem5/pull/341
Change-Id: If00049eb598f6722285e9e09419aef98ceed759f
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
Adds a new probe listener template which can be used
to instantiate with a lambda function that is called by
notify(). It is similar to ProbeListenerArg with class but
provides more flexibility. I.e. the can be another object
than the one instantiating the lambda which allows to listen
to any object. Furthermore additional parameters can be
passed in easily.
Change-Id: Iba451357182caf25097b9ae201cd5c647aff3a4f
Signed-off-by: David Schall <david.schall@ed.ac.uk>
At the moment the instruction is disassembled as an integer
operation:
msrNZCV x547, x0
Instead of
msr nzcv x0
Change-Id: I3f6576dccbe86db401c73747750ca3cfdf4055d5
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
