ThumbEE had already been removed but there were still some
references to it dangling around. We were also signaling
ThumbEE as being available through HWCAPS in SE which
was not correct. This patch is fixing it
Change-Id: I8b196f5bd27822cd4dd8b3ab3ad9f12a6f54b047
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Sets the appropriate bit in the ID_AA64ZFR0_EL1 sysreg that declares
support for ARMv8.2-F64MM.
This indicates that all pre-requisites for Armv8.2 SVE FP64
double-precision floating-point matrix multiplication instructions
have been met.
FMMLA, and LD1RO* instructions have been implemented, as well as the
128-bit element variants of TRN1, TRN2, UZP1, UZP2, ZIP1, and ZIP2.
For more information please refer to the "ARM Architecture Reference
Manual Supplement - The Scalable Vector Extension (SVE), for ARMv8-A"
(https://developer.arm.com/architectures/cpu-architecture/a-profile/
docs/arm-architecture-reference-manual-supplement-armv8-a)
Additional Contributors: Giacomo Travaglini
Change-Id: Idac3a3ca590e6eb2beb217a40a8c10af1e917440
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70729
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Add support for the Arm SVE Floating Point Matrix Multiply-Accumulate
(FMMLA) instruction. Both 32-bit element (single precision) and 64-bit
element (double precision) encodings are implemented, but because the
associated required instructions (LD1RO*, etc) have not yet been
implemented, the SVE Feature ID register 0 (ID_AA64ZFR0_EL1) has only
been updated to indicate 32-bit element support at this time.
For more information please refer to the "ARM Architecture Reference
Manual Supplement - The Scalable Vector Extension (SVE), for ARMv8-A"
(https://developer.arm.com/architectures/cpu-architecture/a-profile/
docs/arm-architecture-reference-manual-supplement-armv8-a)
Additional Contributors: Giacomo Travaglini
Change-Id: If3547378ffa48527fe540767399bcc37a5dab524
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70726
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Apply the gem5 namespace to the codebase.
Some anonymous namespaces could theoretically be removed,
but since this change's main goal was to keep conflicts
at a minimum, it was decided not to modify much the
general shape of the files.
A few missing comments of the form "// namespace X" that
occurred before the newly added "} // namespace gem5"
have been added for consistency.
std out should not be included in the gem5 namespace, so
they weren't.
ProtoMessage has not been included in the gem5 namespace,
since I'm not familiar with how proto works.
Regarding the SystemC files, although they belong to gem5,
they actually perform integration between gem5 and SystemC;
therefore, it deserved its own separate namespace.
Files that are automatically generated have been included
in the gem5 namespace.
The .isa files currently are limited to a single namespace.
This limitation should be later removed to make it easier
to accomodate a better API.
Regarding the files in util, gem5:: was prepended where
suitable. Notice that this patch was tested as much as
possible given that most of these were already not
previously compiling.
Change-Id: Ia53d404ec79c46edaa98f654e23bc3b0e179fe2d
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46323
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The only thing left in isa_traits.hh are two constants, one for the
number of bytes in a page, and one for how far to shift an address to
get the page number. To make it clear that this is the only thing
isa_traits.hh should be used for from this point forward (until it is
entirely eliminated), this change renames it to the much less generic
page_size.hh.
Also, because isa_traits.hh used to have *much* more stuff in it, it was
included in a lot of places it didn't need to be. This change also
clears out all these legacy includes while updating the actually needed
ones to the new name.
Change-Id: I939b01b117c53d620b6b0a98982f6f21dc2ada72
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40179
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Most ISAs used that constant exactly once, when setting up a Process.
This change just propogates the constant to the one place it's used. In
MIPS, the endianness is hard coded as little. There were some checks
which would change the behavior if the endianness was big. This change
removes that dead code. If someone wants to add support for big endian
MIPS, they can go back and add in the small bits of code that would be
required. It's likely the existing big endian support was incomplete and
not tested, so it's probably best for someone interested in it to start
fresh anyway.
Change-Id: Ife6ffcf4bca40001d5d9126f7d795f954f66bb22
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40178
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
The systemc dir was not included in this fix.
First it was identified that there were only occurrences
at 0, 1, and 2 levels of indentation (and 2 of 2 spaces,
1 of 3 spaces and 2 of 12 spaces), using:
grep -nrE --exclude-dir=systemc \
"^ *enum [A-Za-z].* {$" src/
Then the following commands were run to replace:
<indent level>enum X ... {
by:
<indent level>enum X ...
<indent level>{
Level 0:
grep -nrl --exclude-dir=systemc \
"^enum [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^enum ([A-Za-z].*) \{$/enum \1\n\{/g'
Level 1:
grep -nrl --exclude-dir=systemc \
"^ enum [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^ enum ([A-Za-z].*) \{$/ enum \1\n \{/g'
and so on.
Change-Id: Ib186cf379049098ceaec20dfe4d1edcedd5f940d
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43326
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The create() method on Params structs usually instantiate SimObjects
using a constructor which takes the Params struct as a parameter
somehow. There has been a lot of needless variation in how that was
done, making it annoying to pass Params down to base classes. Some of
the different forms were:
const Params &
Params &
Params *
const Params *
Params const*
This change goes through and fixes up every constructor and every
create() method to use the const Params & form. We use a reference
because the Params struct should never be null. We use const because
neither the create method nor the consuming object should modify the
record of the parameters as they came in from the config. That would
make consuming them not idempotent, and make it impossible to tell what
the actual simulation configuration was since it would change from any
user visible form (config script, config.ini, dot pdf output).
Change-Id: I77453cba52fdcfd5f4eec92dfb0bddb5a9945f31
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35938
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The System class has a few different arrays of values which each
correspond to a thread of execution based on their position. This
change collects them together into a single class to make managing them
easier and less error prone. It also collects methods for manipulating
those threads as an API for that class.
This class acts as a collection point for thread based state which the
System class can look into to get at all its state. It also acts as an
interface for interacting with threads for other classes. This forces
external consumers to use the API instead of accessing the individual
arrays which improves consistency.
Change-Id: Idc4575c5a0b56fe75f5c497809ad91c22bfe26cc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25144
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The components in base/loader were moved into a namespace called
Loader. This will make it easier to add loader components with fairly
short natural names which don't invite name collisions.
gem5 should use namespaces more in general for that reason and to make
it easier to write independent components without having to worry about
name collisions being added in the future.
Unfortunately this namespace has the same name as a class used to load
an object file into a process object. These names can be disambiguated
because the Process loader is inside the Process scope and the Loader
namespace is at global scope, but it's still confusing to read.
Fortunately, this shouldn't last for very long since the responsibility
for loading Processes is going to move to a fake OS object which will
expect to load a particular type of Process, for instance, fake 64 bit
x86 linux will load either 32 or 64 bit x86 processes.
That means that the capability to feed any binary that matches the
current build into gem5 and have gem5 figure out what to do with it
will likely be going away in the future. That's likely for the best,
since it will force users to be more explicit about what they're trying
to do, ie what OS they want to try to load a given binary, and also
will prevent loading two or more Processes which are for different OSes
to the same system, something that's possible today as far as I know
since there are no consistency checks.
Change-Id: Iea0012e98f39f5e20a7c351b78cdff9401f5e326
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24783
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Switch over to the new MemState API by specifying memory regions for
stack in each ISA, changing brkFunc to use MemState for heap memory,
and calling the MemState fixup in fixupStackFault (renamed to just
fixupFault).
Change-Id: Ie3559a68ce476daedf1a3f28b168a8fbc7face5e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25366
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Extend the MemState API to handle tracking dynamically sized memory
regions of a Process class which may be added, moved, removed, or
change in size during the course of simulation. This utilizes the
virtual memory areas (VMA) class to track individual regions and
provides a fixup method to handle physical page allocation in case of
a page fault. This allows for lazy allocation of the stack, heap, and
mmap regions of memory.
Change-Id: I3ef10657e5f8e8f0e328bdf0aa15a27b1dde39bf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25483
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
The only functional difference between them was that the SE one might
have optionally fixed up missing translations for demand paging.
This lets us get rid of some code recreating the proxy ports in
setProcessPtr since the SE translating port no longer keeps a copy of
the process object pointer.
Change-Id: Id97df1874f1de138ffd4f2dbb5846dda79d9e4ac
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26550
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
A memory image can be described by an object file, but an object file
is more than a memory image. Also, it makes sense to manipulate a
memory image to, for instance, change how it's loaded into memory. That
takes on larger implications (relocations, the entry point, symbols,
etc.) when talking about the whole object file, and also modifies
aspects which may not need to change. For instance if an image needs
to be loaded into memory at addresses different from what's in the
object file, but other things like symbols need to stay unmodified.
Change-Id: Ia360405ffb2c1c48e0cc201ac0a0764357996a54
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21466
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
The interpreter is a separate object file, and while it's convenient to
hide loading it in the code which loads the main object file, it breaks
the conceptual abstraction since you only asked it to load the main
object file.
Also, this makes every object file format reimplement the idea of
loading the interpreter. Admittedly only ELF recognizes and sets up
an interpreter, but other formats conceptually could too.
This does move that limitted hypothetical redundancy out of the object
file formats and moves it into the process objects, but I think
conceptually that's where it belongs. It would also probably be pretty
easy to add a method to the base Process class that would handle
loading an image and also the interpreter image.
This change does not (yet) separate reading symbol tables.
Change-Id: I4a165eac599a9bcd30371a162379e833c4cc89b4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21465
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
The ObjectFile class has hardcoded assumptions that there are three
segments, text, bss and data. There are some files which have one
"segment" like raw files, where the entire file's contents are
considered a single segment. There are also ELF files which can have
an arbitrary number of segments, and those segments can hold any
number of sections, including the text, data and/or bss sections.
Removing this assumption frees up some object file formats from having
to twist themselves to fit in that structure, possibly introducing
ambiguities when some segments may fulfill multiple roles.
Change-Id: I976e06a3a90ef852b17a6485e2595b006b2090d5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21463
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
ELF is, in my opinion, the most important object file format gem5
currently understands, and in ELF terminolgy the blob of data that
needs to be loaded into memory to a particular location is called a
segment. A section is a software level view of what's in a region
of memory, and a single segment may contain multiple sections which
happen to follow each other in memory.
Change-Id: Ib810c5050723d5a96bd7550515b08ac695fb1b02
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21462
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
The AuxVector type has a bunch of accessors which just give access to
the underlying variables through references. We might as well just make
those members accessible directly.
Also, the AuxVector doesn't need to handle endianness flips itself. We
can tell the byteswap mechanism how to flip an AuxVector, and let it
handle that for us.
This gets rid of the entire .cc file which was complicated by trying
to both hide the ISA specific endianness translations, and instantiate
templated functions in a .cc.
Change-Id: I433cd61e73e0b067b6d628fba31be4a4ec1c4cf0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18373
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
AArch32 and AArch64 have different HWCAP flags in Linux, but we are
currently using AArch32 HWCAP flags to initialize the aux vector of both
AArch32 and AArch64 binaries.
This patch also fixes a bug that was introduced by running in SE mode a
target binary compiled with glibc > 2.18. Using AArch32 flags
resulted on CPUID flag being set for AArch64. This incorrectly tells
libc that emulation of the midr_el1 is supported.
In FullSystem this might work, but since we are in Syscall Emulation
there is no OS behind emulating the mrs midr_el1 instruction.
By separating AArch32 flags from AArch64 flags we are turning off the
CPUID hwcap flag in SE mode.
Change-Id: I9f651957ba9d19dc2bc06606de070c6586f0f9fa
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/12884
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
The AuxVector class is responsible for holding Process data.
The data that it holds is normally setup by an OS kernel in
the process address space. The purpose behind doing this is
to pass in information that the process will need for various
reasons. (Check out the enum in the header file for an idea of
what the AuxVector holds.)
The AuxVector struct was changed into a class and encapsulation
methods were added to protect access to the member variables.
The host ISA may have a different endianness than the simulated
ISA. Since data is passed between the process address space and
the simulator for auxiliary vectors, we need to worry about
maintaining endianness for the right context.
Change-Id: I32c5ac4b679559886e1efeb4b5483b92dfc94af9
Reviewed-on: https://gem5-review.googlesource.com/12109
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.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>
When switching an assert to a fatal while addressing recent review
feedback, I forgot to reverse the polarity of the condition, making
the fatal fire in exactly the opposite of the conditions it was meant
to.
Change-Id: Icf49864ef449052bbb0d427dca786006166575c4
Reviewed-on: https://gem5-review.googlesource.com/7381
Reviewed-by: Matthias Jung <jungma@eit.uni-kl.de>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
