This should be either the fixed index if there are no predicated
operands (ie operands which may not be used), and an auto incrementing
index otherwise. This is still not bulletproof since the auto
incrementing index is just code which ++-es the index, and so the index
will be different and incremented each time that value is substituted
in.
Also, the mixture of predicated operands and the vector operands is
broken and will not generate compilable code, but I'm not going to try
to fix that here.
Change-Id: I1ceae519649762e54eaa019610e51bb8c21d28d6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42970
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
These are currently only used in the reg, float and media ops, but
should be expanded to the other types eventually. This is part of an
attempt to use common machinery for the microops instead of having
each type recreate the mechanisms it needs locally.
Change-Id: I67f521b6b161310ba50a30ac4c73305cc75a63d5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42969
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Instead of having a bunch of implicit integer registers which are
identified only by number, except in the ISA description where there are
operands hard coded to certain numeric offsets into the implicit
registers, and having an independent count of those implicit registers,
just create a set of named indices for the registers we need.
Redefine NUM_INTREGS to be the total number of registers, and
NUM_ARCH_INTREGS to be the number of architectural integer registers.
Instead of using NUM_INTREGS as a coincidental short hand for the first
microop register (since that comes after the architectural ones), and
implicitly knowing that that's the zero register, define an INTREG_T0
constant which at least makes it clear what register we're talking
about, even if it's not clear that the semantics of that register make
it mostly a placeholder.
Change-Id: I5fa41169b9619ea68a50d6d5241ff9a07440bceb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42523
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Re-upload of https://gem5-review.googlesource.com/c/public/gem5/+/41214
This provides a layer of indirection where the rounding mode
setting/getting code will do nothing if fenv.h isn't available. At build
time, if fenv.h can't be found, a warning is printed.
Also, the include for fenv.h was guarded in the includes in the ISA
header, but the functions from it weren't guarded in the actual code.
Finally, the code was setting the rounding mode, but not setting it
back. That would mean running these instructions would set the rounding
mode in gem5 as a whole, affecting its other behaviors and any other
instructions that might expect the default rounding mode.
Change-Id: I3ff2b97189487579554aae890e14889bd63461d2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44085
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The code in the body of a DPRINTF will always be compiled, even if it's
disabled. If TRACING_ON is false, the if around it will short circuit to
false without actually running any code to check the specified
condition, and the body of the if will be elided by the compiler as
unreachable code.
This creates a more consistent environment whether TRACING_ON is on or
not, so that variables which are only used in DPRINTF don't have to be
guarded by their own TRACING_ON #ifs at the call site. It also ensures
that the code inside DPRINTF is always checked to be valid code, even if
the DPRINTF itself will never go off. This helps avoid syntax errors,
etc, which aren't found because of the configuration of the build being
tested with.
Change-Id: Ia95ae229ebcd2fc9828f62e87f037f76b9279819
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44988
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
These would extract particular numbered source or destination registers
from an instruction and feed them into a printReg method. Now that the
register operands know how to print themselves with printReg directly,
these methods are no longer used.
Change-Id: I4244cb2ee97015f51f4783f377282e2a1db5d69b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42363
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These methods had looked up the register index using an index into the
src or dest index arrays. This level of indirection is less efficient
than using the index itself (which we know already), and also requires
that the array is layed out like how we think it is.
Before:
array idx => reg idx => folded?
After:
reg idx => folded?
Change-Id: Ice2262250ff77582ba5530fc52e6738ba1bebe18
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42356
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These were a weird holdover from when register indices were all squished
into a single scalar value, offset based on the register type. When that
change happened, the person who made it misunderstood what the
InstRegIndex type was for, and decided to build RegId into it for some
reason. The only purpose of InstRegIndex is to make sure everybody
agrees that the value being passed around is going to be used as a
register index and not a literal value, or vice versa. There is no type
associated with it as far as floating point, integer, or misc registers.
That gets applied at a different step, and actually can't be part of
InstRegIndex since the same base class may need to hold register indices
that are going to be treated as integer or floating point depending on
the subclass using them.
Also, since the values of the various constants in the DepdenceTags enum
where never actually added into register indices in the first place, the
code in the InstRegIndex constructor would never do anything. All
registers would be arbitrarily sorted into Int, FP, etc, and then when
they actually went to be used the category would be thrown away.
Change-Id: I8c4e8d6e9cdb53e298c00ad2f56e8c7304e51e96
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40339
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
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>
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>
