Rather than force all x86 microops to have one destination and two
sources, the second of which is a register or immediate, make it
possible for these microops to pick any combination of those elements by
modularizing the operand aspects of the base class. This prevents having
a bunch of extra parameters and members of the classes, or having a lot
of explicitly laid out classes with various combinations.
This also improves the accuracy/usefulness of Exec traces since register
types and therefore names will be determined correctly.
Also, there was a branchTarget override added to all register uops which
would be used when the macroop was an direct control transfer
instruction. The assumption was that the immediate value of the whole
instruction would be the PC offset, which is not necessarily correct but
is probably a fairly safe assumption.
This override was only provided for all *register* uops though, and
there's nothing saying the last uop in a branch instruction has to be a
a register uop. This change moves that override to the uop base class so
that *any* uop can be last in the macroop and still support branchTarget
correctly (or at least as correctly as a register uop would).
Change-Id: I9d42d22609d511fa757a784c04a5a9874beca479
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42343
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
It looks like this script was intended to be used to generate config.ini
files from a given gem5 configuration, although some of the functions
and paths it uses are quite obsolete and won't work any more, for
instance m5execfile and the util/pbs directory.
The currently recommended way to generate a config.ini file is to run a
configurtion up to the point it would be generated and then stop it,
that *will* work today, and while it's not necessarily elegant to have
to run a simulation to an arbitrary point and then kill it, relying on
the config.ini itself, an intermediate artifact, is also not
particularly elegant.
Rather than move this script to util or config, either of which would be
a more appropriate home for it, and then also attempting to fix it up to
work with modern gem5, where it may then still sit unused and forgotten,
it's better to just delete it and rely on the other existing method.
Change-Id: I1ae2842730bbe5e76549eb1d962d7d30fb5edfc0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45167
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
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 "UnitTest" would compile against and exercise the various stats
types in gem5, but did not verify that anything that happened was
correct. It was also not really a unit test in the sense that while it
did try to do something fairly specific, it did that using an
arbitrarily large portion of gem5.
Actual unit tests using the googletest framework are a more appropriate
way to test these mechanisms.
Change-Id: I3b424e9f5ffcf41f7de1cb42e6a222bf1c40054a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45166
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This "UnitTest" actually links against all of gem5, and can be used to
look at a binary and find either what symbol goes with an address, or
what address goes with a symbol.
While that could be a useful thing to want to do, there are other ways
to do that with external tools. Also, other than by seeing if this tool
compiles and manually seeing if it returns reasonable results, this
doesn't really actually test anything.
Finally, this is one of the old style "UnitTest"s, quotes intentional,
since while it may try to do a fairly specific thing, it actually
exercises an arbitrarily large portion of gem5 as a whole to do it, does
not self report success or failure, contain any test cases or input data
or expected output, and is not run automatically as part of our testing
suite.
Tests for the underlying classes in the Loader namespace would be/are
more appropriate, and make this test unnecessary.
Change-Id: I48db315d3da440fd26be0a81cc8e07affcacda46
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45165
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This changes the base classes for load-store instructions
and introduces two new classes for DS form instructions
which use a shifted signed immediate field as the offset
from the base address and for X form instructions which
use registers for both the offset and the base address.
The formats have also been updated to make use of the new
base classes.
Change-Id: Ib5d1bb5d7747813e0e5b1e3075489f1a3aa72660
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40892
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This extends the ACPI implementation to support the MADT. This table
contains information about the interrupt system (Local APIC, IO-APIC)
and partially replaces the Intel MP tables.
The change is particularly needed to support other OSes than Linux that
do not support Intel MP.
Change-Id: I132226f46f4d54e2e0b964e2986004e3e5f5f347
Signed-off-by: Maximilian Stein <m@steiny.biz>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41953
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The RSDP points to the RSDT (32 bit) and/or the XSDT (64 bit), which are
both instances of the abstract System Description Table.
This commit implements the mechanism to write the three data structures
to memory based on the full system's configuration. The SysDescTable
class acts as base class for the RSDT and XSDT as well as any future
implementation of other System Description Tables.
Change-Id: I710279a72376c04f2a636ff2e96fa80228d03eaf
Signed-off-by: Maximilian Stein <m@steiny.biz>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42824
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When RS and RA are both used as operands by an instruction,
RS takes precedence over RA. In such cases, either both the
register operands are used as sources or RS is a source and
RA is a destination.
This changes the order by giving RS the highest precedence
and will be useful for proper disassembly generation.
Change-Id: If351a03a814653f2f371afa936ec7a5cd4377b3a
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40890
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The initial device contains enough code for the gpufs configuration
scripts to register an amdgpu device that identifies as a Vega 10
(Frontier Edition) device when PCI devices are listed by Linux. It also
contains stubs necessary for adding the MMIO interface to handle driver
initialization.
Using the configuration Linux boots and the device is successfully seen
in lspci. The driver can also begin loading an successfully sends
initial MMIOs and attempts to read the ROM.
Change-Id: I7ad87026876f31f44668e700d5adb639c2c053c1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44909
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This macro is directly expecting a Debug::Flag instance as a first
argument instead of simply the name of the debug flag, and it is
forwarding it with no preprocessing to the underlying logic
(dprintf_flag).
This is different from the common DPRINTF, which is converting the
first argument into a flag and into a string literal.
This is useful if we want to pass the DebugFlag from the subclass to
the superclass. This makes it possible to set tracepoints in the
Base class logic, and let the Derived classes define the flag which
will enable the tracepoint
class Base
{
Base(const Debug::SimpleFlag &_flag)
: flag(_flag) {}
void baseLogic()
{
DPRINTFV(flag, "...");
}
const Debug::SimpleFlag flag;
}
class Derived1 : public Base
{
Derived1() : Base(Debug::Derived1) {}
}
class Derived2 : public Base
{
Derived2() : Base(Debug::Derived2) {}
}
A more concrete example is Arm Table Walker, which is using a DmaPort.
If we want to log the table walker port activity, we are using the
--debug-flags=DMA, which is unconvenient as it will contain the
logs from every DMA device in the simulation
Change-Id: I793cf1521303fd0a3bbea2059a9447386f83661e
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44967
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This adds the definition of the Target Address Register (TAR)
and the following instructions that are associated with it.
* Move To Target Address Register (mttar)
* Move From Target Address Register (mftar)
* Branch Conditional to Branch Target Address Register (bctar[l])
Change-Id: I30f54ebd38b503fb6c9ba9dd74d00ccbbc0f8318
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40889
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Among the register-based conditional branch instructions,
the ones using CTR should not decrement CTR when the bit
corresponding to this action is set in the BO field of
the instruction. In this case, the instruction should be
considered invalid. This fixes the following instructions.
* Branch Conditional to Count Register (bcctr[l])
Change-Id: Ib2dbf2bc36fced580b4b7f7b76783f68361f6bbf
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40887
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This changes the base classes for branch instructions and
switches to two high-level classes for unconditional and
conditional branches. The conditional branches are further
classified based on whether they use an immediate field or
a register for determining the target address.
Decoding has also been consolidated using formats that can
generate code after determining if an instruction branches
to an absolute address or a PC-relative address, or if it
implicitly sets the return address by looking at the AA and
LK bits.
Change-Id: I5fa7db7b6693586b4ea3c71e5cad8a60753de29c
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40886
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When multiple instructions share the same primary opcode,
the decoder can distinguish between them by looking at the
extended opcode field. However, the length and position of
the extended opcode field can slightly vary depending on
the instruction form.
This ensures that the correct extended opcode fields are
used for decoding such instructions.
Change-Id: I8207568ac975587377abba8a9b221ca3097b8488
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40885
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Rather than decode and call each PsuedoInst function one by one, we can
use a GuestABI which knows how to marshal arguments and return values
and call the pseudoInst dispatch function which will do the work for us,
and make SPARC able to call any pseudo inst, not just the ones it was
hard coded to recognize.
Change-Id: I28192c4feeaf86a77c0f23c5b131929e45ec6d74
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42388
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Only one is set up corrent, the one passed in from the constructor.
Others can be added with addThreadContext.
The inconsistency of adding one ThreadContext through the constructor
and others through addThreadContext isn't great, but this way we can
ensure that there is always at least one ThreadContext. I'm not sure
what the GDB stub should do if there aren't any threads. I don't think
that the protocol can actually handle that, judging from the
documentation I can find.
Change-Id: I9160c3701ce78dcbbe99de1a6fe2a13e7e69404e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44611
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>
Distinguish between the 'g' and 'c' subcommands. 'c' sets what thread(s)
should be continued or single stepped when those commands are used, and
'g' sets what thread(s) should be used for anything else. Also, insist
that all threads are used for continuing or single stepping.
Still complain if we're asked to switch threads, since we only have one
and we can't change to anything else.
Change-Id: Ia15c055baba48f75fc29ef369567535b0aa2c76b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44609
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Just because the current methods of the base class only call
Event::trace from within DTRACE(Event), that's no guarantee that future
methods will, that the call sites won't be changed so that they don't,
or any number of subclasses that may not even exist today will.
Instead, we should incur the very slight overhead of checking the
Debug::Event variable again to ensure expected behavior, and to avoid
unnecessary complexity for a very small optimization when we're already
enabled a high overhead behavior like tracing for all events in a
virtual function.
Change-Id: I1c360b2ba73ad73c0658e85e9122f1fef07f93ce
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44986
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is aligning with RISCV and X86. Prior to this patch the Arm
TableWalker was using the TLBVerbose flag. We now use the generic
PageTableWalker flag, in most of the table walker code.
We still rely on the TLBVerbose for some methods.
Those are not conceptually related to the table walker:
For example the memAttrs methods are populating the TLB entry fields
before inserting it in the TLB. Describing the entry fields is
not strictly related to the walking mechanism
Change-Id: Ia75fef052cd44905cc41247f8e590e3ce3912252
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44966
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There is a design which has been put forward which eliminates the idea
of a zero register entirely, but in the mean time, to get rid of one
more ISA specific constant, this change moves the ZeroReg constant into
the RegClassInfo class, specifically the IntRegClass instance which is
published by each ISA.
When the idea of zero registers has been eliminated entirely from
non ISA specific code, this and the existing machinery can be
eliminated.
Change-Id: I4302a53220dd5ff6b9b47ecc765bddc6698310ca
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42685
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Gem5 defines several types of memory access including normal read,
normal write, atomic operations. For now we only support normal read
and normal write converting from SystemC via TLM2. To support atomic
operations from SystemC, we add an atomic extension. A SystemC model can
fire a atomic request with the extension.
The extension mainly has two attributes. One is a AtomicOpFunctor which
is the implementation of the atomic operation. The other one is bool
which indicates the gem5 request flag should be ATOMIC_RETURN_OP or
ATOMIC_NO_RETURN_OP.
Change-Id: I817727dd4b2d357667f928063210c58a44c81afb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44525
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
The GPU VIPER TCC protocol accidentally used "TiggerMsg" instead
of "TriggerMsg" for the triggerQueue_in port. This was a benign
bug beacuse the msg type is not used in the in_port implementation
but still makes the SLICC harder to understand, so fixing it is
worthwhile.
Change-Id: I88cbc72bac93bcc58a66f057a32f7bddf821cac9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44905
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The arch/generic/types.hh header includes some more complicated types
which in turn bring in more dependencies, adding baggage when other code
only needs the simple RegIndex or ElemIndex types. Also the RegVal type
alias is already in base/types.hh. It doesn't really make sense to have
RegVal in one header and RegIndex in another.
Change-Id: I1360652598b5fa59e0632b1ee0e0535ace2ba563
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42966
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Commit id ef44dc9a removed mmap-based doorbell allocation since dGPUs
use ioctl's instead. However, APUs still need this to work correctly.
Add that logic back in as well as some new logic to distinguish doorbells
mmaps from other types. Also add some additional commentary regarding
Event page mmaps.
Change-Id: I8507ac85c8f07886d0fb4f95bde5e18a7790eab8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42218
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
