| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I9f208819b8c1a5c46a77262eb533bb47adb2b905
Reviewed-on: https://gem5-review.googlesource.com/7701
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
If set, the granularity bit indicates that the segment limit of segment
descriptors shall be interpreted as number of 4K blocks rather than
bytes.
The high part (bit 48 to 51) of segment descriptor limits is only 4 bits
wide while the low part (bit 0 to 15) spans 16 bits.
Change-Id: Ie386224ca815275fdb31498fe68310ed9c62cc87
Reviewed-on: https://gem5-review.googlesource.com/7601
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This patch adds support for cache flushing instructions in x86.
It piggybacks on support for similar instructions in arm ISA
added by Nikos Nikoleris. I have tested each instruction using
microbenchmarks.
Change-Id: I72b6b8dc30c236a21eff7958fa231f0663532d7d
Reviewed-on: https://gem5-review.googlesource.com/7401
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Rather than store the actual TLB entry that corresponds to a mapping,
we can just store some abstracted information (address, a few flags)
and then let the caller turn that into the appropriate entry. There
could potentially be some small amount of overhead from creating
entries vs. storing them and just installing them, but it's likely
pretty minimal since that only happens on a TLB miss (ideally rare),
and, if it is problematic, there could be some preallocated TLB
entries which are just minimally filled in as necessary.
This has the nice effect of finally making the page tables ISA
agnostic.
Change-Id: I11e630f60682f0a0029b0683eb8ff0135fbd4317
Reviewed-on: https://gem5-review.googlesource.com/7350
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The new version extracts all the x86 specific aspects of the class,
and builds the interface around a variable collection of template
arguments which are classes that represent the different levels of the
page table. The multilevel page table class is now much more ISA
independent.
Change-Id: Id42e168a78d0e70f80ab2438480cb6e00a3aa636
Reviewed-on: https://gem5-review.googlesource.com/7347
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Use the system object to allocate physical memory instead of manually
placing certain structures and then forcing the system to start other
allocations after them in physical memory.
Change-Id: Ie18c81645c3b648c64a6d7a649a0e50f7028f344
Reviewed-on: https://gem5-review.googlesource.com/7346
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
|
|
Pass this constant into the page table constructor.
Change-Id: Icbf730f18d9dfcfebd10a196f7f799514728b0fb
Reviewed-on: https://gem5-review.googlesource.com/7345
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
|
|
Don't get it from a global constant declared in an ISA header file.
Change-Id: Ie19440abdd76500a5e12e6791e6f755ad9e95af3
Reviewed-on: https://gem5-review.googlesource.com/7344
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
This avoids having a copy in the lookup function itself, and the
declaration of a lot of temporary TLB entry pointers in callers. The
gpu TLB seems to have had the most dependence on the original signature
of the lookup function, partially because it was relying on a somewhat
unsafe copy to a TLB entry using a base class pointer type.
Change-Id: I8b1cf494468163deee000002d243541657faf57f
Reviewed-on: https://gem5-review.googlesource.com/7343
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Fold the GDBListener class into the main BaseRemoteGDB class, move
around a bunch of functions, convert a lot of internal functions to
be private, move some functions into the .cc, make some functions
non-virtual which didn't really need to be overridden.
Change-Id: Id0832b730b0fdfb2eababa5067e72c66de1c147d
Reviewed-on: https://gem5-review.googlesource.com/7422
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Now that Nothing inherits from PageTableBase directly, it can be
merged into FuncPageTable. This change also takes the opportunity to
rename the combined class to EmulationPageTable which lets you know
that it's specifically for SE mode.
Also remove the page table entry cache since it doesn't seem to
actually improve performance. The TLBs likely absorb the majority of
the locality, essentially acting like a cache like they would in real
hardware.
Change-Id: If1bcb91aed08686603bf7bee37298c0eee826e13
Reviewed-on: https://gem5-review.googlesource.com/7342
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This breaks one more architecture dependence outside of the ISAs.
Change-Id: I071f9ed73aef78e1cd1752247c183e30854b2d28
Reviewed-on: https://gem5-review.googlesource.com/6982
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
|
|
This gets rid of an awkward NoArchPageTable class, and also gives the
arch a place to inject ISA specific parameters (specifically page size)
without having to have TheISA:: in the generic version of these types.
Change-Id: I1412f303460d5c43dafdb9b3cd07af81c908a441
Reviewed-on: https://gem5-review.googlesource.com/6981
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This constant is, first, a #define, and second only used in one place.
In that one place, it appears that the code it guards is no longer
necessary in general. It was originally written to avoid refetching a
block of data that you're still in, even if you've moved slightly
farther in it because you're skipping the next instruction due to an
annulled branch delay slot. In reality however, in SPARC, the one ISA
I'm aware of which has this sort of branching behavior, the PC state
object will correctly determine that no branch is happening in these
cases. Code lower down in the loop will then recompute where fetching
should continue based on the next PC, automatically skipping the
annulled branch slot without misinterpretting the gap as a branch.
This change therefore also removes this block of code.
Change-Id: I820ebc9df10aeb4fcb69c12f6a784e9ec616743c
Reviewed-on: https://gem5-review.googlesource.com/6821
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
It's no longer used.
Change-Id: I4a71bcb214f1bb186b92ef50841eca635e6701c5
Reviewed-on: https://gem5-review.googlesource.com/6826
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
That particular ExtMachInst is a convenient placeholder, but a value
of 0 in RISCV or a static uninitialized ExtMachInst (which will
therefore be all zeroes) on x86 works just as well, and removes the
need for an ISA specific constant.
Also, the idea of a universal Nop doesn't always make sense since it
could be that what, exactly, doesn't do anything depends on context
which would be lost on a constant value of an ExtMachInst. For
instance, the value of an ExtMachInst that makes sense might depend on
what mode the CPU was in, etc.
Change-Id: I1f1a43a5c607a667e11b79bcf6e059e4f7141b3f
Reviewed-on: https://gem5-review.googlesource.com/6825
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Alec Roelke <ar4jc@virginia.edu>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
CPUs have historically instantiated the architecture specific version
of the TLBs to avoid a virtual function call, making them a little bit
more dependent on what the current ISA is. Some simple performance
measurement, the x86 twolf regression on the atomic CPU, shows that
there isn't actually any performance benefit, and if anything the
simulator goes slightly faster (although still within margin of error)
when the TLB functions are virtual.
This change switches everything outside of the architectures themselves
to use the generic BaseTLB type, and then inside the ISA for them to
cast that to their architecture specific type to call into architecture
specific interfaces.
The ARM TLB needed the most adjustment since it was using non-standard
translation function signatures. Specifically, they all took an extra
"type" parameter which defaulted to normal, and translateTiming
returned a Fault. translateTiming actually doesn't need to return a
Fault because everywhere that consumed it just stored it into a
structure which it then deleted(?), and the fault is stored in the
Translation object when the translation is done.
A little more work is needed to fully obviate the arch/tlb.hh header,
so the TheISA::TLB type is still visible outside of the ISAs.
Specifically, the TlbEntry type is used in the generic PageTable which
lives in src/mem.
Change-Id: I51b68ee74411f9af778317eff222f9349d2ed575
Reviewed-on: https://gem5-review.googlesource.com/6921
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
GCC 7.2 is much stricter than previous GCC versions. The following changes
are needed:
* There is now a warning if there is an implicit fallthrough between two
case statments. C++17 adds the [[fallthrough]]; declaration. However,
to support non C++17 standards (i.e., C++11), we use M5_FALLTHROUGH.
M5_FALLTHROUGH checks for [[fallthrough]] compliant C++17 compiler and
if that doesn't exist, it defaults to nothing (no older compilers
generate warnings).
* The above resulted in a couple of bugs that were found. This is noted
in the review request on gerrit.
* throw() for dynamic exception specification is deprecated
* There were a couple of new uninitialized variable warnings
* Can no longer perform bitwise operations on a bool.
* Must now include <functional> for std::function
* Compiler bug for void* lambda. Changed to auto as work around. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82878
Change-Id: I5d4c782a4e133fa4cdb119e35d9aff68c6e2958e
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/5802
Reviewed-by: Gabe Black <gabeblack@google.com>
|
|
This means the instruction is treated as cmpxchg8b when the effective
operand size is 16 bits.
Change-Id: I4d9bb295f96097e1746a9bbccb2c579d14738fab
Reviewed-on: https://gem5-review.googlesource.com/6603
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Replace them with std::array<>s.
Change-Id: I76624c87a1cd9b21c386a96147a18de92b8a8a34
Reviewed-on: https://gem5-review.googlesource.com/6602
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
Explicitly separate the way the data is represented in the underlying
representation from how it's represented in the instruction.
In order to make the ISA parser happy, the Mem operand needs to have
a single, particular type. To handle that with scalar types, we just
used uint64_ts and then worked with values that were smaller than the
maximum we could hold. To work with these new array values, we also
use an underlying uint64_t for each element.
To make accessing the underlying memory system more natural, when we
go to actually read or write values, we translate the access into an
array of the actual, correct underlying type. That way we don't have
non-exact asserts which confuse gcc, or weird endianness conversion
which assumes that the data should be flipped 8 bytes at a time.
Because the functions involved are generally inline, the syntactic
niceness should all boil off, and the final implementation in the
binary should be simple and efficient for the given data types.
Change-Id: I14ce7a2fe0dc2cbaf6ad4a0d19f743c45ee78e26
Reviewed-on: https://gem5-review.googlesource.com/6582
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Print faulting instruction for unmapped address panic in faults.cc
and print extra info about corresponding fetched PC in base.cc.
Change-Id: Id9e15d3e88df2ad6b809fb3cf9f6ae97e9e97e0f
Reviewed-on: https://gem5-review.googlesource.com/6461
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The FSW and TOP values are technically part of the same register, but
they have very different behaviors. One of them can be renamed and
float along without affecting global state, while the other requires
serialization. They just need to *look* like the same register when
read by the user.
Also, there was a missing break in setMiscRegNoEffect.
Change-Id: If58de0f566f65068208240f4001209fb9e1826d6
Reviewed-on: https://gem5-review.googlesource.com/6441
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The microcode for those instructions needs a directive which overrides
that setting in the instructions emulation environment.
Reported-by: Matt Sinclair <mattdsinclair@gmail.com>
Change-Id: I474d938c0b3cf01da92ec817a58b08de783f1967
Reviewed-on: https://gem5-review.googlesource.com/6301
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
These files aren't a collection of miscellaneous stuff, they're the
definition of the Logger interface, and a few utility macros for
calling into that interface (panic, warn, etc.).
Change-Id: I84267ac3f45896a83c0ef027f8f19c5e9a5667d1
Reviewed-on: https://gem5-review.googlesource.com/6226
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
In the ISA instruction definitions, some classes were declared with
execute, etc., functions outside of the main template because they
had CPU specific signatures and would need to be duplicated with
each CPU plugged into them. Now that the instructions always just
use an ExecContext, there's no reason for those templates to be
separate. This change folds those templates together.
Change-Id: I13bda247d3d1cc07c0ea06968e48aa5b4aace7fa
Reviewed-on: https://gem5-review.googlesource.com/5401
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Alec Roelke <ar4jc@virginia.edu>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
The ISA parser used to generate different copies of exec functions
for each exec context class a particular CPU wanted to use. That's
since been changed so that those functions take a pointer to the base
ExecContext, so the code which would generate those extra functions
can be removed, and some functions which used to be templated on an
ExecContext subclass can be untemplated, or minimally less templated.
Now that some functions aren't going to be instantiated multiple times
with different signatures, there are also opportunities to collapse
templates and make many instruction definitions simpler within the
parser. Since those changes will be less mechanical, they're left for
later changes and will probably be done in smaller increments.
Change-Id: I0015307bb02dfb9c60380b56d2a820f12169ebea
Reviewed-on: https://gem5-review.googlesource.com/5381
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
When decoding VEX prefixed instructions, the x86 predecoder wasn't walking
past the opcode byte and so was also interpreting it as the modRM byte.
Reported-by: likunxi@fas.harvard.edu
Change-Id: I6d4bdabfa03411704c48d905c50c7b23072fc615
Reviewed-on: https://gem5-review.googlesource.com/5281
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Generating dependency/build product information in the isa parser breaks scons
idea of how a build is supposed to work. Arm twisting it into working forced
a lot of false dependencies which slowed down the build.
Change-Id: Iadee8c930fd7c80136d200d69870df7672a6b3ca
Reviewed-on: https://gem5-review.googlesource.com/5081
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
ARM systems require the coordination of the global and local
monitors. When the system is run without caches the global monitor is
implemented in the abstract memory object. This change adds a callback
from the abstract memory that notifies the local monitor when the
global monitor is cleared.
Additionally, for ARM systems the local monitor signals the event
register and wakes the thread context up. Subsequent wait-for-event
(WFE) instructions will be immediately signaled.
Change-Id: If6c038f3a6bea7239ba4258f07f39c7f9a30500b
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/3760
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
MOV Rd,Cd is MR encoded but the control register is operand 2
not operand 1 hence this needs to be MODRM_REG not MODRM_RM.
While MOV Cd,Rd is RM encoded registers are also swapped, so
it also needs to be MODRM_REG as well (as it already correctly is).
This fixes incorrect UD2 reportings leading to invalid traps
reported in O3 on X86 FS introduced with 4e939a7 .
Change-Id: Ib33c8ba87b00e0264d33da44fff64ed9e4d2d9d8
Reviewed-on: https://gem5-review.googlesource.com/4861
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
The kernel stat mechanism should really be refactored and moved somewhere
else, but in the mean time there's some old cruft that can be cleared away.
Change-Id: I21e725de590dda0d20bf3bc675bbe976c7b1bd86
Reviewed-on: https://gem5-review.googlesource.com/4600
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Change-Id: Ie5ef1aaaef46cf8ef8fa4b0fc8f7efb8cde9b489
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/4283
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
The condition is whether the control register index is valid.
Change-Id: I8a225fcfd4955032b5bbf7d3392ee5bcc7d6bc64
Reviewed-on: https://gem5-review.googlesource.com/4581
Reviewed-by: Michael LeBeane <Michael.Lebeane@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
A condition can be specified which will tell the decoder whether to return
the instruction being requested, or, if the condition fails, UD2.
Change-Id: I0f1c075deb10754ce1dd88be1726a196294e41fd
Reviewed-on: https://gem5-review.googlesource.com/4580
Reviewed-by: Michael LeBeane <Michael.Lebeane@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This fixes the function call to clone in syscall_emul.hh where
the x86 version should be called before the base implementation
of clone.
Change-Id: Iccd2f680ff6e3a5536037d688a80ab3f236bbd98
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3902
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
Change-Id: Iebf7d245de66eebc8d4c59e62e52adf6cf51e1e4
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3980
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
Change-Id: I09570e569efe55f5502bc201e03456738999e714
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3920
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
This patch adds some more functionality to the cpu model and the arch to
interface with the vector register file.
This change consists mainly of augmenting ThreadContexts and ExecContexts
with calls to get/set full vectors, underlying microarchitectural elements
or lanes. Those are meant to interface with the vector register file. All
classes that implement this interface also get an appropriate implementation.
This requires implementing the vector register file for the different
models using the VecRegContainer class.
This change set also updates the Result abstraction to contemplate the
possibility of having a vector as result.
The changes also affect how the remote_gdb connection works.
There are some (nasty) side effects, such as the need to define dummy
numPhysVecRegs parameter values for architectures that do not implement
vector extensions.
Nathanael Premillieu's work with an increasing number of fixes and
improvements of mine.
Change-Id: Iee65f4e8b03abfe1e94e6940a51b68d0977fd5bb
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
[ Fix RISCV build issues and CC reg free list initialisation ]
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2705
|
|
With the hierarchical RegId there are a lot of functions that are
redundant now.
The idea behind the simplification is that instead of having the regId,
telling which kind of register read/write/rename/lookup/etc. and then
the function panic_if'ing if the regId is not of the appropriate type,
we provide an interface that decides what kind of register to read
depending on the register type of the given regId.
Change-Id: I7d52e9e21fc01205ae365d86921a4ceb67a57178
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
[ Fix RISCV build issues ]
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2702
|
|
Replace the unified register mapping with a structure associating
a class and an index. It is now much easier to know which class of
register the index is referring to. Also, when adding a new class
there is no need to modify existing ones.
Change-Id: I55b3ac80763702aa2cd3ed2cbff0a75ef7620373
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
[ Fix RISCV build issues ]
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2700
|
|
Change-Id: Ie1df07b70776208fc3631a73d403024636fc05a9
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3749
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
|
|
Change-Id: I912601b6f781a0bbedd06583c059589374f6d5c6
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3720
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Joe Gross <joe.gross@amd.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
GDB breaks if more bytes are sent than the transmitted registers
actually need. Therefore the GdbRegCache struct needs to be packed to
prevent padding at the end.
Change-Id: Ib2c14eb70becdac609eb4f475d5dddbd5bcc60da
Signed-off-by: Matthias Hille <matthiashille8@gmail.com>
Reviewed-on: https://gem5-review.googlesource.com/3020
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
Remove redundant information from the ExtMachInst, hash the vex
information to ensure the decode cache works properly, print the vex info
when printing an ExtMachInst, consider the vex info when comparing two
ExtMachInsts, fold the info from the vex prefixes into existing settings,
remove redundant decode code, handle vex prefixes one byte at a time and
don't bother building up the entire prefix, and let instructions that care
about vex use it in their implementation, instead of developing an entire
parallel decode tree.
This also eliminates the error prone vex immediate decode table which was
incomplete and would result in an out of bounds access for incorrectly
encoded instructions or when the CPU was mispeculating, as it was (as far
as I can tell) redundant with the tables that already existed for two and
three byte opcodes. There were differences, but I think those may have
been mistakes based on the documentation I found.
Also, in 32 bit mode, the VEX prefixes might actually be LDS or LES
instructions which are still legal in that mode. A valid VEX prefix would
look like an LDS/LES with an otherwise invalid modrm encoding, so use that
as a signal to abort processing the VEX and turn the instruction into an
LES/LDS as appropriate.
Change-Id: Icb367eaaa35590692df1c98862f315da4c139f5c
Reviewed-on: https://gem5-review.googlesource.com/3501
Reviewed-by: Joe Gross <joe.gross@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
|
|
When the LiveProcess class was renamed to be just Process, the CL author
also changed the syscall function from a virtual function into a regular
one. Unfortunately, the I386Process class overrode the syscall function
to adjust the return address so that control would return to the right
place. Without that adjustment, 32 bit x86 process would segfault and die
immediately after their first system call.
This change reinstates the virtual specifier on the base syscall function,
and adds an override keyword on the I386Process's version so that it won't
be orphaned again in the future. It also fixes some small style issues the
style checker script complained about.
Change-Id: I0d1178ea0eda6676050c8fc043820a2bb4d99c0d
Reviewed-on: https://gem5-review.googlesource.com/3500
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
The new version modularizes the implementation of the various commands,
gets rid of dynamic allocation of the register cache, fixes some small
style problems, and uses exceptions to simplify error handling internal to
the GDB stub.
Change-Id: Iff3548373ce4adfb99106a810f5713b769df89b2
Reviewed-on: https://gem5-review.googlesource.com/3280
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
If the operands were 64 bit, an intermediate calculation could lose a
carry bit. This change rearranges that intermediate calculation if the
operand width is large, and reworks the microop implementation in general
in an attempt to make it easier to understand.
Change-Id: Ib36333f3f2695a33cd9623e43682de22ebd2e7ea
Reviewed-on: https://gem5-review.googlesource.com/3381
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
|
|
When a branch micro-op belongs to a flow and the micro-op does not change
the nPC and just updates the nuPC (like a 'rep movs' flow), branching()
function always returns not-taken no matter actual micro-branch outcome.
Provided fix adds to the equation nuPC attribute checking since these kind
of branch micro-op only updates that pointer.
This issue has been found while debugging the performance of a copy-loop
implemented with memcopy function. Without the fix, 'rep movss' internal
micro-branch was always predicted as not-taken causing an squash event
after every branch micro-branch execution.
Using the provided test, branch mispredition went from 1922 without the fix
to 7.
Change-Id: I1bcbefae26aef47e3135817ef99b53d0ea0a98fa
|
|
This changeset sets the implementation policy for a subset of
system calls to the ignoreFunc implementation (for x86 only).
The ignored system calls likely will never be implemented and
this allows a warning to be issued instead of the simulation
exiting with a fatal.
Change-Id: I8d9741ad683151e88cc71156d3602e2d0ccb0acf
Reviewed-on: https://gem5-review.googlesource.com/2270
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Tony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Michael LeBeane <Michael.Lebeane@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
