These currently only hold the number of registers in a particular class,
but can be extended in the future to hold other information about each
class. The ISA class holds a vector of descriptors which other parts of
gem5 can retrieve to set up storage for each class, etc.
Currently, the RegClass enum is used to explicitly index into the vector
of descriptors to get information about a particular class. Once enough
information is stored in the descriptors, the other parts of gem5 should
be able to set up for each register class generically, and the ISAs will
be able to leave out or create new register classes without having to
set up global plumbing for it.
The more immediate benefit is that this should (mostly) parameterize
away the ISA register constants to break another TheISA style
dependency. Currently a global set of descriptors are set up in the
BaseISA class using the old TheISA constants, but it should be easy to
break those out and make the ISAs set up their own descriptors. That
will bring arch/registers.hh significantly closer to being eliminated.
Change-Id: I6d6d1256288f880391246b71045482a4a03c4198
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41733
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This was set to 1, the same as SSrcReg1. That value is used to order the
registers in the source operand array. Other code then expects to find
operands in that order when, for example, looking up an index to pick
sub-parts of a register out, or to print a register name.
Since the index value of SSrcReg1 and SSrcReg2 were the same, they
wouldn't be sorted in a predictable way, meaning the code looking for
SSrcReg2's index might have found SSrcReg1's index instead and done the
wrong thing.
Change-Id: I75045e64595e249802f57d22023a7eeb7b8ac5c6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42342
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Override ParseParam<>::parse and ShowParam<>::parse directly. This will
allow using a different format for serializing and displaying registers.
Also get rid of the print() methods. When any cprintf based mechanism is
used (like DPRINTF), the underlying mechanism will use << to output the
value. Since we already override <<, there's no reason to wrap that in a
method which calls csprintf which calls << anyway.
Change-Id: Id65b9a657507f2f2cdf9673fd961cfeb0590f48c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41994
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
This function causes problems with gcc 5 which incorrectly complains
about the call to warn_if inside a constexpr function. That should only
be an error if a call to a non-constexpr is unavoidable, and even then
the compiler isn't required to emit a diagnostic.
Rather than drop the warning, or add ifdefs to deal with these defective
versions of gcc, this change eliminates the power() function entirely.
Most inputs to this function would overflow anyway, which is reportedly
why no integer version of an exponentiation function is defined in the
standard library, and all uses of this function can easily and more
efficiently be replaced by simple left and right shifts.
Finally, by eliminating the power() function, we also remove the
dependence on base/logging.hh.
Change-Id: I4d014163883d12db46da4ee752696c8225534ee8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42504
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The yieldThread function implements MIPS's yield instruction, and had a
if condition in it, (src_reg && !yield_mask != 0), which upset clang. When
originally committed, this check read (src_reg & !yield_mask != 0), but
apparently as part of a cleanup sweep a long time ago, it was assumed
that the & was being used as a logical operator and was turned into &&.
Reading the actual description of what the yield instruction is supposed
to do, if src_reg is positive (it is at this point in the function),
then it's supposed to be treated as a bitvector. The YQMask register,
what gets passed in as yield_mask, can have bits set in it which mask
bits that might be set in src_reg, and if any are still set, the an
interrupt should happen, as implemented by the body of the if.
From this description, it's apparent that what the original code was
*trying* to do was to use yield_mask to mask any set bits in src_reg,
and then if any bits were left go into the body. The original author
used ! as a bitwise negating operator since what they *wanted* to do was
to block any bits in src_reg where yield_mask *is* set, and let through
any where yield_mask *is not* set. The & would do that, but only with a
bitwise negated yield_mask. Hence:
if ((src_reg & ~yield_mask) != 0) {
...
}
Change-Id: I30d0a47992750adf78c8aa0c28217da187e0cbda
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40957
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Due the compute unit pipeline being executed in reverse order, there
exists a scenario where a compute unit will execute an extra
instruction when it's supposed to be stopped at a barrier. It occurs
as follows:
* The ScheduleStage sets a barrier instruction ready to execute.
* The ScoreboardCheckStage adds another instruction to the readyList.
This is where the barrier is checked, but because the barrier isn't
executing yet, the instruction can be passed along to ScheduleStage
* The barrier executes, and stalls
* The ScheduleStage sees that there's a new instruction and schedules
it to be executed.
* Only now will the ScoreboardCheckStage realize a barrier is active
and stall accordingly
* The subsequent instruction executes
This patch sets the wavefront status to be S_BARRIER in ScheduleStage
instead of in the barrier instruction execution in order to have
ScoreboardCheckStage realize that we're going to execute a barrier,
preventing it from marking another instruciton as ready.
Change-Id: Ib683e2c68f361d7ee60a3beaf53b4b6c888c9f8d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41573
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Each vectorReg operand defined a set of seven elements which all
followed a very predictable pattern. Since we already have a small
utility function to help generate those definitions, we can just
generate the elements at the same time and save a lot of boilerplate.
Change-Id: I065c6c319612b79c53570b313bf5ad8770796252
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41896
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch implements the CLINT device model based
on the SiFive U54MC datasheet. CLINT is modelled to
receive its clock signal via an interrupt pin. A
generic RTC (non-MMIO) is also implemented to provide
this signal at arbitrary frequencies.
isa.cc is also modified to provide a correct implementation
of the rdtime instruction. It will read from the miscreg
file (which is updated by CLINT every time mtime is
incremented).
Change-Id: I6f5393f3a8fdbd059f25df51d3d74bcb28da09f1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40597
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Since the RISC-V privileged specs V1.11 did not specify
an implementation of physical memory attributes (PMA), e.g.
cacheability, an abstract PMAChecker class is created. This
class acts as a generic PMAChecker hardware without any
latency modelling.
The TLB finds the PMAChecker defined at the MMU level by
Parent.any.
Change-Id: I4400133895be44da67536d80b82422ec3a49d786
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40596
Reviewed-by: Ayaz Akram <yazakram@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 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>
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>
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>
The idea of this template was to distinguish types which should
grow/shrink based on the native size of the ABI in question. Or in other
words, if the ABI was 32 bit, the type should also be 32 bit, or 64 bit
and 64 bit.
Unfortunately, I had intended for Addr to be a conforming type (since
local pointers would be conforming), but uint64_t not to be. Since Addr
is defined as a typedef of uint64_t, the compiler would make *both*
types conforming, giving incorrect behavior on 32 bit systems.
Local pointers will need to be handled in a different way, likely with
the VPtr template, so that they will be treated correctly and not like
an explicitly 64 bit data type.
Change-Id: Idfdd5351260b48bb531a1926b93e0478a297826d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40495
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This type is primarily used to determine the size of a pointer when
using that ABI, similar to the uintptr_t type, but also less directly
to determine the "native" size of the ABI. For instance, for 32 bit ARM
ABIs, it should be defined as uint32_t since that's both the size of a
uintptr_t, and, less directly, the size of a 32 bit ARM register and
"naturally" sized types in that ABI.
This type can be used by the VPtr template to retrieve its actual value
from a simcall's parameters. In general, when accepting or returning a
pointer or address in a simcall, the VPtr template should be used so
that it's managed correctly by GuestABI. Addr will be treated as a
uint64_t allways which will be incorrect for 32 bit ABIs.
Change-Id: I3af046917387541d6faff96a21a1f1dbf7317e06
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40496
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
This DPRINTF accesses the ExtMachInst typed machInst member of the
StaticInst class, and so is ISA dependent. Move the DPRINTF to where the
instructions are actually decoded where that type doesn't have to be
disambiguated.
Also, this change makes this DPRINTF more accurate, since microops are
not really "decoded" when they are extracted from a macroop. The process
of unpacking them to feed into the rest of the CPU should be fairly
trivial, so really they're just being retrieved. With the DPRINTF in
this new position, it will only trigger when an instruction is actually
decoded from memory.
Change-Id: I14145165b93bb004057a729fa7909cd2d3d34d29
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40099
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
