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>
Original Creator: Adria Armejach.
Branch instructions needed to be annotated in x86 as direct/indirect and conditional/unconditional. These annotations where not present causing the branch predictor to misbehave, not using the BTB. In addition, logic to determine the real branch target at decode needed to be added as it was also missing.
Change-Id: I91e707452c1825b9bb4ae75c3f599da489ae5b9a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/29154
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The "hello" tests that were previously ignored are all functioning
correctly, and are therefore being re-included in the test suite. The
MIPS and SPARC tests have been tagged a "long" as we do not compile
these ISAs are part of our "quick" tests.
Change-Id: I3aa079b81b938a12da6993213d158e53bc4ae514
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32914
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 code was at least a little Alpha specific, and now that Alpha is
gone it can no longer be compiled. We could either fix it up to work
with other/all ISAs or delete it, and the consensus was to delete it. It
could potentially be revived in the future by retrieving it from version
control.
Change-Id: Ied073f2b9b166951ecba3442cd762eb19bc690b3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32954
Reviewed-by: Steve Reinhardt <stever@gmail.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Also remove it's Alpha centric implementation. All existing ISAs will
panic since they all define the guarding constant as false. Even if they
defined it as true, this function assumes that there is necessarily a misc
reg which can be read to find the current thread_info struct, and how
the contents of that register should be manipulated.
This code is already fairly fragile since it depends on things in the
Linux kernel having certain names and relationships with each other, but
that's a larger problem I don't want to fix right now.
Change-Id: Ic107793ebcd25ee25c4d3713c84c1d2b5209f1a3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32921
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
