The patch is using the newly defined PARAMS macro to replace
custom params() getters in derived class.
The patch is also removing redundant _params:
Instead of creating yet another _params field, SimObject descendants
should use params() to expose the real type of SimObject::_params they
already have.
Change-Id: I43394cebb9661fe747bdbb332236f0f0181b3dba
Signed-off-by: Alexander Klimov <Alexander.Klimov@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39900
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This function is not used anywhere.
In addition, gethostname uses a fixed host name, and
sethostname is not implemented (sim/syscall_emul). If
we were to handle sethostname too it would require a
special conjoint implementation anyway.
Change-Id: I20919a49b123a6a49582d9cfacf1fd167cb44776
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41394
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously converting scientific numbers to non-floating
numbers would yield incorrect results, because the
underlying conversion was using stoll and stoull, which
do not deal with scientific numbers properly. Therefore,
converting to_number("8.234e+08", val) would yield
val=8, which is blatantly wrong (expected 823400000).
This was fixed by searching for "e" within the string to
be converted.
To make sure all double and scientific number conversions
are correct, a few extra tests were added.
Change-Id: I6a9599d8473909d274326b6f8c268e3603044ab4
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38775
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
A single functionalRead may not be able to get the whole latest
copy of the block in protocols that have features such as:
- a cache line can be partially present and dirty in a controller
- a cache line can be transferred over the network using multiple
protocol-level messages
To support these cases, this patch adds an alternative function:
bool functionalRead(PacketPtr, WriteMask&)
Protocols that implement this function can partially update
the packet and use the WriteMask to mark updated bytes.
The top-level RubySystem:functionalRead then issues functionalRead
to controllers until the whole block is read.
This patch implements functionalRead(PacketPtr, WriteMask&) for all the
common messages and SimpleNetwork. A protocol-specific implementation
will be provided in a future patch.
The new interface is compiled only if required by the protocol (see
src/mem/ruby/system/SConscript). Otherwise the original interface is
used thus maintaining compatibility with previous protocols.
Change-Id: I4600d5f1d7cc170bd7b09ccd09bfd3bb6605f86b
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31416
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Adds additional stats to accounts for incoming and outgoing retries.
Calling incomingTransactionStart with retried==true indicates the
received request initiating the transaction is a retried request.
Calling outgoingTransactionEnd with retried==true indicates the request
was retried by the requester.
Change-Id: I22fd971d4997fce0c114b5ec030cbbf9b463d0c6
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41158
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The mismatches were from places where Params structs had been declared
as classes instead of structs, and ruby's MachineID struct.
A comment describing why the warning had been disabled said that it was
because of libstdc++ version 4.8. As far as I can tell, that version is
old enough to be outside the window we support, and so that should no
longer be a problem. It looks like the oldest version of gcc we
support, 5.0, corresponds with approximately libstdc++ version 6.0.21.
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html#abi.versioning
Change-Id: I75ad92f3723a1883bd47e3919c5572a353344047
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40953
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When building with clang with the --without-tcmalloc flag set, the
-fno-builtin flag is not used, and clang can then detect that the
integer version of abs(), apparently the C version, is being used on a
floating point value in traffic_gen.cc.
This change takes clang's suggestion to use std::abs instead, and also
includes a header file which will provide it.
Change-Id: Ic28ed7454b2ac00c89328d9d0314aed74e946643
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41597
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The name of the build is opt, so it should be fully optomized. Also, the
fast build, the only one with LTO historically, is dangerous to use
since it disables many error checks. I personally run gem5 many times
while developing, iterating and trying to fix bugs, and so want it to
run quickly then too, not just the final time when collecting results.
Also, since they mirror the opt build, the perf and prof builds also
have LTO options added.
This has the nice side effect of speeding up the build time of build/X86
significantly (6:20 -> 4:27) due to parallelization of the link, and
reduces the size of the build/X86 directory (with debug compression
enabled) from 3.4GB to 2.8GB.
The size of build/X86/python/_m5 is still 1.6GB, so still more than half
of the total size of build/X86.
Change-Id: I8feabf99454693fdd100d9e1a64fdeae53362f75
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40815
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Earl Ou <shunhsingou@google.com>
The operators it seems to need are ones which modify the BitUnion being
operated on, vs ones which just use it to produce a new value. The later
kind can be handled by converting the BitUnion into its underlying type
and then applying the built in operators.
Change-Id: I8aa08bf74d8ad88f4dfbb0031610c52ad412d03b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41515
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The TBEStorage is used to track the resources consumed by the TBETable,
i.e. the number of available TBE slots.
structure(TBEStorage, external ="yes") {
int size();
int capacity();
int reserved();
int slotsAvailable();
bool areNSlotsAvailable(int n);
void incrementReserved();
void decrementReserved();
int addEntryToNewSlot();
void addEntryToSlot(int slot);
void removeEntryFromSlot(int slot);
}
TBEStorage resource tracking has two main differences from TBETable:
1) Allows slot reservation. This is useful to implement protocols that
employ retry/credit messages instead of stall when the controller runs
out of TBEs to accept new request.
2) Can also assign multiple entries to the same slot. This is useful to
more easily model cases where multiple transactions share the same TBE
resource (i.e. the slot).
E.g: a request that triggers a replacement in a system without
dedicated WB/Eviction buffer; both transactions can can have separate
logical TBEs associated to the same slot.
The motivation for having a separate structures for tracking TBEs
availability are twofold:
- Keeps TBETable simple and without the additional overhead for
protocols that do not need these additional features.
- Having two separate transactions sharing the same TBE resource using
the current TBETable would be cumbersome since the TBETable is indexed
by the transaction address.
Change-Id: I64106d50068320bc925243732ef8ff9ef0b6c4bf
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41157
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In the background, scons invokes commands using what is essentially
'sh -c ${CMD}'. It's a little more sophisticated than that, but the net
effect is that all of the arguments of a given command are collected
into a single argument for sh. While Linux has a very generous limit
on the number of command line arguments you can have, and a relatively
generous limit on the total size of the arguments and environment
variables which can be read with "getconf ARG_MAX" (about 2MB only my
system), the limit on an individual argument, defined in the little
documented constant MAX_ARG_STRLEN, is much smaller, 32 pages or
131072 bytes from what I've read.
Unfortunately, when building gem5, especially without partial linking,
the command line for the final linking step can be very long, and with
some extra files brought in with EXTRAS can relatively easily exceed
this limit.
To work around this problem, this change adds a new scons "tool" which
replaces the SPAWN and PSPAWN construction environment variables (not
the shell environment, scon's env, aka main) with wrappes. These
wrappers create a temporary file, write the command into it, and then
tell the original SPAWN/PSPAWN implementation to run that file as the
actual command.
This works, but it has two potential drawbacks. First, it creates
extra temporary files which may add some overhead to the build. The
overhead is likely small, but is non-zero.
Second, while this restores the original breaks between command line
arguments, it doesn't completely avoid the total argument/environment
size limit which would be harder to hit, but does still exist.
Another option would be to use the same sort of technique, but to use
gcc's (and I assume clang's) ability to read options from a file using
an @file argument, where file is replaced with the name of the
arguments.
The upside of this approach is that it avoids all of these limits
since gcc is just reading a file, and the only limits are ones it self
imposes. Also, this would only apply to invocations of gcc, and so
would be worth plumbing in to only affect, say, the linking step.
There would be no hypothetical overhead from creating temp files.
One downside though, is that this is not a universal approach and
would break anything which doesn't understand @file style arguments.
Also, when intercepting calls to the shell, the arguments we're
getting have been made appropriate for that environment (escaping,
quoting, etc). The rules for escaping arguments in an @file may not be
quite the same as for the shell, and so there may be weird cases where
a command line gets garbled this way.
Given the tradeoffs, I think always putting the commands into temp
files and running them as scripts is the way to go.
Change-Id: I0a5288aed745a432ed72ffd990ceded2b9422585
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41273
Reviewed-by: Earl Ou <shunhsingou@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This very small kernel module seems to be intended to measure the access
time to device registers when running in a linux kernel. It mentions
kernel version 2.6.x and so is fairly old and may not work with modern
kernels.
While there is probably some utility (no pun intended) to having a
driver like that and that sort of measurement capability, the usefulness
is probably not huge compared to its small but non-zero maintenance
burden. It seems like it's not something that gets active attention
given it's revision history, and is probably just taking up space these days.
Change-Id: I3b1f44d718d7e6ee23695e3117bb169268f2157a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41473
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This script is basically a wrapper around scons. Since scons is already
a pretty robust python based build environment, there doesn't seem to be
much need to add another python wrapper around it.
Also, this script is quite out of date. For instance, it only mentions
SPARC and MIPS (it used to mention ALPHA, but that was deleted), and
still makes reference to separate _FS and _SE builds which haven't been
a thing for many years.
Change-Id: I0e9fefaa5b3c2d092f70ad01b904eb7e64e5361e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41455
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add a DMA thread tester to the Ruby GPU tester to test the DMA state
machine in the protocol. Currently creates a dummy DMA device to pass
through Ruby.py and scans for the DMA sequencers due to opaqueness of
Ruby.py.
DMA atomics not yet supported as there is no protocol that implements
atomic transitions in the DMA state machine file.
Example run command:
build/GCN3_X86/gem5.opt configs/example/ruby_gpu_random_test.py \
--test-length=1000
Change-Id: I63d83e00fd0dcbb1e34c6704d1c2d49ed4e77722
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39936
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When calling TryCompile with an empty string for the source, useful
when just testing a build flag, some versions of SCons will apparently
create some sort of equivalence between Value('') and Value(0). That
shows itself when creating config file headers, where Value(0) is
switched with Value(''), and the header defines a macro with which
expands to nothing rather than a macro which expands to 0. Later uses
of the macro of the form:
#if CONFIG_VARIABLE
fail because CONFIG_VARIABLE expands to nothing. If it expanded to 0
like it's supposed to, then the guarded block of code would be excluded
correctly.
Change-Id: Ie324ec5f8dd307c65745b9326a11230e10caa0bd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41213
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
While the wakeUpBuffers/wakeUpAllBuffers check all message buffers,
wakeup_port wakes up only the messages stalled on the specified port
and address. Usage is the same as the stall_and_wait statement, e.g.:
wakeup_port(reqInPort, addr);
Change-Id: I57dc77d574c0016ca55786ce16a73061a1d37f2e
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41155
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Certain branch instructions specify that the result of (simm16 * 4)
gets sign-extended before being added to the PC.
Previously, that result was being sign extended as if it was still a
16-bit number. This patch fixes that by having the result be sign
extended as an 18-bit number.
Change-Id: Id4d430f8daa71ca7910b570e7e39790626f1decf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41053
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
