This change adds a wrapper for the ScalarInfo stat type to enable
introspection of scalar stats from Python. Due to the slightly
confusing use of proxy objects in the stat system, PyBind11 fails to
automatically cast to the right wrapper type. This is worked around in
the by explicitly casting to the relevant type's Python wrapper.
To make the interface more Python-friendly, this change also changes
the semantics of resolveStat to raise an exception if the stat can't
be found.
Change-Id: If1fc6fe238fc9d69d4e22369a4988a06407d2f7c
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33176
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There isn't anything special about using the page size, and it creates
an artificial dependence on the ISA. Instead of being based on pages,
the cache is now based on "chunks" who's size is a template parameter.
It defaults to 4K which is a common page size, but it can be tuned
arbitrarily if necessary.
Some unnecessary includes have been trimmed out as well.
Change-Id: I9fe59a5668d702433a800884fbfbdce20e0ade97
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33204
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
isa_traits.hh used to have much more in it, but now it only has
PageShift, PageBytes, and (for now) the guest endianness. These values
should only be retrieved from the System class generally speaking, so
only the system class should include arch/isa_traits.hh.
Some gpu compute related files need PageBytes or PageShift. Even though
those files don't advertise their ISA dependence, they are tied to x86.
In those files, they can include arch/x86/isa_traits.hh.
The only other file which legitimately needs arch/isa_traits.hh is the
decoder cache since it uses PageBytes to size an array.
Change-Id: I12686368715623e3140a68a7027c136bd52567b1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33203
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The 'jalr' instruction of 'format Jump' should have an immediate as
offset, and the Rd register could not be always omitted. This patch
fixes the problem.
Example output:
jalr ra, -168(ra)
jalr zero, 0(ra)
jalr ra, 0(a5)
Note that this does not apply to the other two instructions of the
same format: 'c.jr' and 'c.jalr'.
Change-Id: Ia656c2e8bfafd243bfec221ac291190a84684929
Signed-off-by: Ian Jiang <ianjiang.ict@gmail.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33155
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 VAddr class wasn't used and was just a copy (with style fixes) of
the Alpha version.
Delete unused constants in isa_traits.hh, and remove unnecessary
includes. Replace MachineBytes with sizeof(uint32_t) in
arch/power/process.cc.
Change-Id: Ia4862448c43b2dd07078b1ebbbbfda4636343730
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33199
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 flat instructions, wrLmReqsInPipe/rdLmReqsInPipe are decremented
in the calcAddr() function. However, the calcAddr() function is only
called when execMask != 0.
This patch adds in statements to decrement wrLmReqsInPipe and
rdLmReqsInPipe in all implemented atomic flats when execMask is 0.
This fixes a scenario where vector local memory and flat instructions
are unable to execute due to LocalMemPipeline::isLMReqFIFOWrRdy
always returning false in ScheduleStage::dispatchReady after too many
atomic flats execute with execMask = 0
Change-Id: I081cfd3faf74bbfcf0728445e7160fa2a76a6a7e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32614
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The default encoding for python 2 is ascii which can't handle some
characters in, for instance, people's names which have accented letters.
This change explicitly selects the utf-8 encoding which pacifies python
and is mostly equivalent except in these rare cases.
In python 3, the default encoding is utf-8 to begin with, and it's no
longer possible to change it. In this case, explicitly selecting the
encoding is redundant but harmless.
When we support only python 3, then this change can be reverted.
Thanks to Lakin Smith for proposing a related solution and pointing out
some information that led to this one.
Change-Id: I99bd59063c77edd712954ffe90d7de320ade49ea
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33575
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Lakin Smith <lakindsmith@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
The CU would initialize its ports in getMasterPort(), which
is not desirable as getMasterPort() may be called several
times for the same port. This can lead to a fatal if the CU
expects to only create a single port of a given type, and may
lead to other issues where stat names are duplicated.
This change instantiates and initializes the CU's ports in the
CU constructor using the CU params.
The index field is also removed from the CU's ports because the
base class already has an ID field, which will be set to the
default value in the base class's constructor for scalar ports.
It doesn't make sense for scalar port's to take an index because
they are scalar, so we let the base class initialize the ID to
the invalid port ID.
Change-Id: Id18386f5f53800a6447d968380676d8fd9bac9df
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32836
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
A completed TLM transaction includes request and response parts.
Currently, if a gem5 packet does not need a reponse, the bridge would not
send BEGIN_RESP to its upstream. It causes stuck on TLM side.
To fix this problem, the bridge should send BEGIN_RESP by itself in this
case.
Change-Id: I318dec21bc3f291693715c0d70bc624addf05076
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32735
Reviewed-by: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This is no longer willing to implicitly cast between the locally defined
Linux::fd_set type and the system fd_set type. That's pretty reasonable
since those types are really independent of one another, and we
shouldn't be using them interchangeably in the first place. That's a
pre-existing condition though, and I just want to get the existing code
to compile for now.
Change-Id: I41d5f3695dfe5f0e406d074d31d13c6e3282df64
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33415
Reviewed-by: Ciro Santilli <ciro.santilli@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>
After this change, if you use these classes or inherit from these
classes, the compiler will now give you a warning that these names are
deprecated. Instead, you should use ResponsePort and RequestPort,
respectively.
This patch simply deprecates these names. The following patches will
convert all of the code in gem5 to use these new names. The first step
is converting the class names and the uses of these classes, then we
will update the variable names to be more precise as well.
Change-Id: I5e6e90b2916df4dbfccdaabe97423f377a1f6e3f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32308
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There are times when we need to change the name of parameter, but this
breaks the external-facing python API used in configuration files. Using
this "type" for a parameter will warn users that they are using the old
name, but allow for backwards compatibility.
Declaring a SimObject parameter of type `DeprecatedParam` allows the
python configuration files to use the old name transparently. This
leverages some of the SimObject magic to remember the names of
deprecated parameters and the DeprecatedParam object stores the
"translation" from old name to new name.
This has been tested with Ports, "normal" parameters, and SimObject
parameters. It has not been tested with checkpointing as there are no
checkpointing tests in gem5 right now. The testing was manually adding
some deprecated params and checking that config scripts still run
correctly that use the old, deprecated, variables.
Change-Id: I0465a748c08a24278d6b1a9d9ee1bcd67baa5b13
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31954
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
As mentioned on the JIRA issue, uncacheable requests done after
cacheable requests had been done to the address make the cache writeback
and write trash data to memory.
We believe that the kernel must be doing earlier invalidation by set and
way earlier on to prevent this, but that is not implemented in gem5 yet.
The problem can be worked around by booting in atomic without caches and
checkpointing after init, because uncacheable accesses are only done on
early stages of CPU bringup, which is the more common use case anyways.
The aarch64 Linux kernel developers have stated that set and way
invalidates are not going to be used in aarch64, which further reduces the
importance of implementing this immediatly
JIRA: https://gem5.atlassian.net/browse/GEM5-640
Change-Id: Ieba31e707dcc09693d7a87ed9d51c3d1ffa3abe0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33015
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The decorator creates two versions of a class, adding it to the Params
dict multiple times which generates an annoying warning. Alternatively,
the with_metaclass mechanism sets up an alternative base class which
does not create the extra class and doesn't generate the warning.
It may be the case that this generates extra classes which just don't
lead to a warning? Or in other words, would we then have Params types
with weird, internal names generated by six? Hopefully not, but that may
be preferable to the annoying warnings, especially when running tests
which run gem5 many times.
Change-Id: I9395cde3fc95126c0a0c4db67fc5b0c6bf2dd9ed
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33276
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This test does two things. First, it makes sure that the "inst" call
type detects that it's being requested in the command line arguments
correctly.
Second, it detects whether it's running in gem5 or not, really just
detecting an environment variable which tells it whether it is. If it
is, then it attempts to run the "sum" op which it expects to succeed and
give the right answer.
If not, it expects to get a SIGILL signal from the OS when it tries to
execute the otherwise illegal instruction. It sets up a signal handler
to catch it, and in that handler saves off information about what
happened. It then uses siglongjmp to return to sanity (before the
signal) and to examine what happened to see if the right instruction was
attempted.
It looks like, depending on the architecture, Linux will either set
si_code to ILL_ILLOPC (illegal opcode) or ILL_ILLOPN (illegal operand).
The later doesn't seem right since the entire instruction is illegal,
not just some operand, but it is what it is and we need to handle
either.
The test then calls a small function, abi_verify, which takes the
siginfo_t and does any abi specific verification. That includes
extracting fields from the instruction if the instruction trigger the
signal, or checking for architecture specific constants, etc.
Also, to centralize setting the macro which lets a call type know that
it's the default, the call types are now also responsible for setting up
their own tweaks to the environment.
Change-Id: I8710e39e20bd9c03b1375a2dccefb27bd6fe0c10
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27689
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Creation of the Compressor namespace. It encapsulates all the cache
compressors, and other classes used by them.
The following classes have been renamed:
BaseCacheCompressor -> Base
PerfectCompressor - Perfect
RepeatedQwordsCompressor -> RepeatedQwords
ZeroCompressor -> Zero
BaseDictionaryCompressor and DictionaryCompressor were not renamed
because the there is a high probability that users may want to
create a Dictionary class that encompasses the dictionary contained
by these compressors.
To apply this patch one must force recompilation (e.g., by deleting
it) of build/<arch>/params/BaseCache.hh (and any other files that
were previously using these compressors).
Change-Id: I78cb3b6fb8e3e50a52a04268e0e08dd664d81230
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33294
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In most cases, the microcode ROM doesn't actually do anything. The
structural existence of a microcode ROM doesn't make sense in the
general case, and in architectures that know they have one and need to
interact with it, they can cast their decoder into an arch specific type
and access the ROM that way.
Change-Id: I25b67bfe65df1fdb84eb5bc894cfcb83da1ce64b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32898
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Some variables were being compared against some constants with "is not",
which is not correct since it will compare for identity rather than
equivalence. There was a long standing build warning from this, but it
wasn't clear where the error was coming from since it was in python
interpreted from a string in the ISA description.
This change replaces "is not" in those two places with "!=".
Change-Id: I0c4d038af6e047ffd79f8171713e8e998e840e3b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33283
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
In sim/vma.hh, the include was indirectly getting the definition of
DPRINTF. It was replaced with an include of base/trace.hh which actually
provides that definition.
In the indirect branch predictor, it was being used to get the
definition of TheISA::PCState. This should come from arch/types.hh
instead.
Change-Id: I6de08f196499c85b54edde09d654902cc766c2eb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33195
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
