By using a PCStateBase pointer or reference, we can (mostly) avoid
having to know what the ISA specific PState class is, letting the ISA
specific instruction classes cast to the type they need internally.
There are a couple minor places where we need to do those casts outside
of ISA specific types, one in the generic NopStaticInstPtr class, and a
few in generic faults.
Right now, we'll just use the TheISA::PCState type in those isolated
spots (sometimes hidden by auto), and deal with it later, possibly
with a virtual "advance" method of some sort.
Change-Id: I774c67dc648a85556230f601e087211b3d5630a9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52043
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Most of the time, the type pointed to by a PCState pointer or reference
will be the same as all the others, if not nullptr.
This change adds a set of "set" functions which assume that the
underlying type of each pointer or reference are the same, and handles
casting, copying things over, creating a new copy, etc, for you. It uses
a new "update" virtual method on PCState subclasses which casts the
source to the same type as the destination and copies values over.
Note that the "set" function doesn't actually verify that the two types
are the same, just like the overloaded ==, != and << operators. In the
future, those checks can be added for debugging purposes, probably
guarded by a configuration variable which can be toggled on or off to
get better performance or more thorough error checking.
The main advantage of these wrappers are that they allows consistent
semantics whether your moving a value from a pointer, or from a yet
unconverted PCState subclass, or vice versa, which will be particularly
helpful while transitioning between using raw PCState instances and
using primarily pointers and references.
This change also adds wrappers which handle std::unique_ptr, which makes
it easier to use them as arguments to these functions. Otherwise, if the
std::unique_ptr is a temporary value, using the return value of .get()
will let the std::unique_ptr go out of scope, making it delete the data
pointed to by the returned pointed. By keeping the std::unique_ptr
around on the stack, that prevents it from going out of scope.
Change-Id: I2c737b08e0590a2c46e212a7b9efa543bdb81ad3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52041
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
This method is the seed which creates a new PCState object of the
appropriate type. It can be used to initialize PCStateBase *s so that they
always point to something valid and can be manipulated without having to
first check if there's something there, as opposed to the alternative
where a pointer might be null until it's first pointed at something.
Change-Id: If06ee633846603acbfd2432f3d8bac6746a8b729
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52040
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Introduce a virtual output() method which prints the current PCState to
the given output stream, and define an overload for << to use that
method. This will make it possible to print a PCState without knowing
what the actual type is.
Change-Id: I663619b168c0b2b90c148b45ae16d77f03934e5b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52039
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
The TraceFile object needs to be registered into the scheduler for
triggering its trace function. For now only the TraceFile created by
sc_create_vcd_trace_file is registered automatically. This design is not
good for users to implement their own TraceFile class.
In addition, some libraries, ex Verilator, implement thier own trace file.
To bridge them into gem5, we also need the ability to create customized
TraceFile class.
Change-Id: I38fe510048655c6a2cd848a0a1263a66a1778eee
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52923
Reviewed-by: Earl Ou <shunhsingou@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This means that if ArchMMU came from the CPU class itself, subclasses
would have a chance to define their own version before the BaseCPU
method consumed it.
The intention is that Arch* *will* be defined in subclasses in later
changes, which will make this more important.
Change-Id: Ib20d5b10aeb26d33840cca4b5a1085d9c73f10de
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52489
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Instead, get the byte order from the workload. The workload has a better
idea what the byte order should be, for instance based on what software
it's loaded or how the hardware was configured, and this gets rid of a
use of TARGET_ISA which was setting a default endianness.
Change-Id: Ic5d8a6f69a664957c4f837e3799ff93397ccfc64
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52106
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
The workload would have a better idea of what it's endianness is than
the system object that holds it. This is the first step towards getting
rid of the getByteOrder method on the system object, which currently
checks TARGET_ISA to determine what the default endianness should be.
If it makes sense for a Workload, it could determine the endianness
dynamically by, for instance, reading it out of a binary image before
putting it into memory.
This does assume that the workload has a consistent endianness
throughout which may not be true, but this is not a new assumption.
Also, mark the SEWorkload SimObject class as "abstract", since it isn't
useful until they get subclassed by some arch specific version.
Change-Id: I8d4ba8382f22236a81f9738cc3506cdb97bdbfb2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52104
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This way there will always be a workload object, even if nothing needs
to be set up. This default can also be used in low_power_sweep.py,
where the workload object was just a placeholder.
This will allow required functionality like determining endianness of a
system into the workload, rather than (for instance) in the more generic
System object. This also makes accessing less essential functionality
simpler, because we don't have to detect whether the workload is there,
and can just return default, placeholder values from the StubWorkload.
Change-Id: Idfc3e75c65318d75a3eae6a19944ae1f79a2d111
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52103
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Also move up the accessors for them. By putting the storage in the base
class, we can keep the accessors non-virtual and keep their overhead
low. Subclasses will be free to set those values to whatever they want
with no overhead, just as if they were natively part of that class.
Change-Id: I58e058def174e0bf591c0a9f050c23f61e9d8823
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52037
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
`setup_memory_ranges()`, now `_setup_memory_ranges()`, had to be called
by subclasses. Since `setup_memory_ranges() was always called at the top
of the `_setup_board()` function (or could be), this function is now
automatically called within the AbstractBoard's constructor prior to
`_setup_board` and `_connect_things`.
Change-Id: I6bf3231666b86059ffc484cfca44e45cfde52ea6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52883
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 order to fix several regression failures [1] the master/slave
terminology in src/cpu/BaseCPU.py was reintroduced [2].
This patch is addressing the issue by providing 2 different
ways of connecting cpu ports:
*) connectBus: The method assumes an object with a bus interface is
passed as an argument, therefore it tries to bind cpu ports to the
bus.mem_side_ports and bus.cpu_side_ports
*) connectAllPorts: No assumption on the port owning device is made.
The method simply accepts ports as arguments which will be directly
connected to the peer cpu ports
This will be used for example by ruby Sequencers
[1]: https://gem5.atlassian.net/browse/GEM5-775
[2]: https://gem5-review.googlesource.com/c/public/gem5/+/34495
Change-Id: I715ab8471621d6e5eb36731d7eaefbedf9663a71
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52584
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
With some values of rotations and datasizes, is it possible to call
"bits" with first being smaller than seccond. To prevent it, rcl,
similar to other rotations had an if to check if the value to rotate
is bigger than 1, however, rcl was checking for 'shiftAmt' instead
of 'realShiftAmt'.
This was not detected before because:
1 - The assert triggered in "bits" is from a recent commit
2 - The result is correct.
Change-Id: I669f4e064e12b035538e5dd0cc61eb4546603512
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52803
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There is a function for this purpose in RegId called flatIndex(), which
I had attempted to use with PhysRegId which inherits from RegId.
Unfortunately, PhysRegId redefines the flatIndex() method and makes it
do something completely different, which is to turn map the index into a
linearization of all registers in the CPU.
Instead of using the decoy wrong method, and because the one we actually
want is not accessible, we can just manually compute the flattened index
in the two places we use it.
Change-Id: I8bd02f0be0f4fb3742da48b2955e9e75ec57245b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52603
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
NMI is platform dependent according to riscv spec, so we intentionally
propose a very minimal design that doesn't give user any new accessible
register to interact with the NMI mechanism.
In current design, the NMI reset vector is fixed to 0x0 and always set
mcause to zero. mret from NMI handler is still possible, but it's up to
the user to detect whether a M-mode trap handler is interrupted and to
recover from it (if at all possible).
1. Add new fault type to represent NMI fault
2. Add non-standard registers to save the status of NMI
a. nmivec[63:2] = NMI reset vector address
b. nmie[0:0] = is NMI enabled = not in NMI handler
c. nmip[0:0] = is NMI pending
3. Add new function in RiscvInterrupts to raise/clear NMI
Bug: 200169094
Test: None
Change-Id: Ia81e1c9589bc02f0690d094fff5f13412846acbe
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52363
Reviewed-by: Yu-hsin Wang <yuhsingw@google.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>
When calling a method in a superclass, you can/should use the super()
method to get a reference to that class. The python 2 version of that
method takes two parameters, the current class name, and the "self"
instance. The python 3 version takes no arguments. This is better for a
at least three reasons.
First, this version is less verbose because you don't have to specify
any arguments.
Second, you don't have to remember which argument goes where (I always
have to look it up), and you can't accidentally use the wrong class
name, or forget to update it if you copy code from a different class.
Third, this version will work correctly if you use a class decorator.
I don't know exactly how the mechanics of this work, but it is referred
to in a comment on this stackoverflow question:
https://stackoverflow.com/questions/681953/how-to-decorate-a-class
Change-Id: I427737c8f767e80da86cd245642e3b057121bc3b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52224
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This enables an SE mode execution of binary if added a Board's
superclass.
This has been abstracted from the SimpleBoard.
The 'set_workload' function has been renamed 'set_se_binary_workload'.
This is clearer on its purpose and doesn't overlap with other
'set_workload' functions.
Change-Id: I714425a3b6b98b91e762ad076eba583bc5953ddd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52186
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
This patch moves 'connect_things' to the AbstractBoard constructor,
thereby meaning it does not need to be called directly in gem5
configuration scripts. This method has been changed to private as a
result.
As boards that inherit from AbstractBoard require certain things to be
setup prior to `connect_things` being called, a new abstract function,
`_setup_board` has been created. This is called in the AbstractBoard
constructor before `connect_things` and can be overridden by boards to
setup board properties as required.
Change-Id: I558a4321b850a6b19e20b7d56d0bcae5805114b6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52184
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The override parameter in the constructor has been renamed to to
'download_md5_mismatch'. This makes the purpose of this parameter
clearer.
The default value has been changed from False to True. We found in most
cases we want to re-download files if the md5 values have changes. Not
wanting to do so is the corner case. This allows us to remove a lot of
parameters from test and example scripts, included in this patch.
Change-Id: I99fc7743f5adf78bf6f4f8efc6222e6df83ac6da
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52086
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
There are some cases where default downloading to `~/.cache/gem5` will
not work (for example, running gem5 in a Docker container, an error
observed here:
https://gem5-review.googlesource.com/c/public/gem5/+/51950).
To fix this, the `_get_default_resource_dir` has been altered to iterate
through a list of default resource directory targets. This change will
mean if `~/.cache/gem5` is not available then the resource is downloaded
to the current working directory of gem5.
Change-Id: I84e523f3adc182e140959243ff9335510d6b7185
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52423
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The purpose of this class is to:
* Create a standard way to set a typical kernel/disk image workload.
* Cleans up the manner in which readfile values/contents are set.
* Allows a user to specify their own kernel arguments, but still sets
sensible defaults.
As of this commit, this interface has been added to the X86Board and the
RISCVBoard.
Change-Id: I34f4c2b829f1ae5c1cae12039436cbb345a89d09
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51949
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously SimpleBoard inherited from AbstractBoard and X86Board and
RiscvBoard inherited from the SimpleBoard. This has been shown to be a
needless level of abstraction. As such, this commit refactors the code
to have X86Board and RiscvBoard inherit directly from AbstractBoard.
Code common to the SimpleBoard, X86Board, and RiscvBoard has been moved
to the AbstractBoard.
Change-Id: I5a2c7404efeb4f8ddcb5d8006e3c163d10b88b2c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51790
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This will let callers create a separate copy of a PCState class
instance. This makes it more explicit when creating copies of a PCState
to make sure the programmer is more aware, and avoids having to know
what the actual type is to make a copy.
Change-Id: I728a278afdb55b800c753a5b7f65f62f4a80c043
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52035
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
These helpers will make it easier to cast a PCStatePtr into an ISA
specific class with less syntactic fluff. They are currently implemented
with a static_cast for performance reasons, but could be implemented
with a dynamic_cast and an assert for extra debugging if you were
willing to pay the performance overhead. In the future this might be
switched/enabled as an extra debugging mode, like how locking can have
extra checks enabled in the Linux kernel.
Change-Id: Ibc2443c6b991ebc2e5d0240a88436849cb6de2b9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52033
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
This class has a lot of common functionality which all PCState classes
use, but in order to make it a true base class which provides the
complete interface for PCState-s throughout gem5, all its methods would
need to become virtual. That doesn't have to be the case today because
we use the literal full ISA specific PC class directly, but we need to
move away from that.
This change leaves PCStateBase empty, since we don't know what will need
to be accessible in base classes through a common/virtual interface.
Also, move methods which do not depend on the InstWidth template
parameter out of SimplePCState and into PCStateCommon. This avoids
having duplicate methods with the same contents which don't depend on
InstWidth.
Change-Id: I31309c4f35e897db1bc8318439fae1567a82b35e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52031
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Earl Ou <shunhsingou@google.com>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
Tested-by: kokoro <noreply+kokoro@google.com>
