These make the calling code in m5.c a little bit more generic. Each call
type will have a function to check the arguments and see if that type is
being requested and/or has any additional options set in the arguments.
If so, those are processed, and argc and argv are adjusted.
Then another function returns the appropriate dispatch table to use for
that invocation scheme. This is behind a function instead of, for
instance, a global variable because it gives the call type a little bit
more control over what's happening, for instance if it would use
different implementations in slightly different circumstances.
Change-Id: I661cf202ec657466496767cbdf331fe27995ab26
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27241
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
I've needed this type of macro often when writing code which uses the
M5OP_FOREACH macro, and so rather than re-write it each time, lets just
put a version here. This is such a common type of macro to need that
you'd think it would be part of a standard header somewhere, but to my
knowledge it isn't.
Change-Id: I0df0d9d2fd7ce1b9e6c355d6e4db197ccfff7c35
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27239
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
It may be the case that each item M5OP_FOREACH iterates over should end
in a ',' and not a ';', for instance when putting each item into an
array or initializing a structure. If the caller still wants a ';', they
can add it into the definition of the M5OP macro.
Change-Id: Idd6538b0aad27df39658c3f749c6ff5e4fe55e6d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27237
Reviewed-by: Bobby R. Bruce <bbruce@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>
These shouldn't be called in fs mode through the m5 utility and
probably shouldn't be called directly either, but this makes them
consistent with the other functions which are mentioned in
asm/generic/m5ops.h.
Change-Id: I80df8b4d507350bc6d2763e770e38e0370931632
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27236
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Make sure all the operations that have constants (and aren't deprecated
or reserved) and present in M5OP_FOREACH in order of their constants.
Also move M5OP_ANNOTATE up so that all the constants are also in order.
Change-Id: I8d9f69b020aeb39311a24606a286a76de10a51cc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27234
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 is a small additional layer on top of the initparam command and
just breaks the returned value into 12 bit chunks. It presumes that
there is some particular meaning to the default initparam value which
may or may not be true. It's not entirely clear what the 12 bit chunks
that this command returns are actually good for, and it's been around
long enough that there isn't really any good documentation about what
it's intended purpose was.
Change-Id: I21af0e0cf7501f47026a6dd31920d46cfccff167
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27232
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Take advantage of string comparisons when looking up what to do with a
given key.
Convert the key_str[12] registers from little endian to host endian.
This matches a corresponding change in the m5 utility to pack the
registers in little endian order, regardless of what the actual guest
endianness is.
Absorb the initparam_keys.hh header into sim/pseudo_inst.cc, and convert
its constants to c++ strings. The constants defined in it might be
useful to guest code calling into the m5 ops, but not for gem5 itself.
By merging them into the .cc file, we also don't have to do any tricks to
try to avoid them having multiple definitions.
Change-Id: I3a450ad7f9c4dca25f79c7835d7f9c167c02ae98
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27230
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
This change removes the responsibility for checking the number of
arguments and handing the default of no string back into init_param and
out of the function which packs strings into registers. It also renames
the function to more closely match its purpose, and rewrites it to be a
bit simpler and (IMHO) easier to follow.
Importantly, rather than doing a hand implemented strcpy which would
follow the endianness of the target/simulated platform, this change
makes this function pack the registers explicitly in little endian byte
order. This way on the consuming end in gem5, the initParam function
doesn't have to care what the guest endianness is, it can just translate
them from little endian to whatever the host endianness is (very likely
also little endian).
Change-Id: Ie9f79ecb8d4584c6e47a2793a31ccaa8c7c15986
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27229
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
If the first register is all zeroes, it doesn't really matter what the
other register is. If the first register has the entire string, we still
don't care what the other register has in it. There's no reason to
complicate the code with these extra checks.
Change-Id: I22ad521b9ace915ccb75f15934fc6b3d650d5293
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27228
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
This command did not use any m5 ops, does the same thing as the
"taskset" command under Linux:
https://linux.die.net/man/1/taskset
and might even have introduced a build error if compiled for any other
OS since that would have left a trailing comma in the mainfuncs array.
While the last problem would be easy to correct, this is not related to
the purpose of this utility (giving access to m5 ops), and is redundant
with an existing standard utility provided with Linux.
Change-Id: Ie72b9310f5e6264f6035013f47ebe74a27464abb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27226
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Because I don't have a canonical toolchain to set SPARC's defaults to,
it will by default build for Linux instead of Solaris like it used to.
This will make it hard to test, but without a compiler there's not much
I can do.
This also coincidentally brings the SPARC version more in line with the
other variants which all target Linux.
Change-Id: Ie19217e988782da124306160920f40ef168840e4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27219
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
SVE half-precision floating-point instructions support only IEEE
754-2008 half-precision format and ignore the value of the FPCR.AHP bit,
behaving as if it has an Effective value of 0.
This patch is addressing this by masking the FPSCR.AHB bit before
passing it to fplib.
Change-Id: I1432fc3f7fefb81445fe042ae7d681f5cec40e64
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28108
Tested-by: kokoro <noreply+kokoro@google.com>
When compiling static objects, disable pie with the -no-pie linker flag.
This is necessary for x86, and doesn't seem to hurt anything for the
other variants.
When compiling shared objects, particularly the assembly files which
can't rely on the compiler to generate position independent code, define
M5OP_PIC so that the assembly code can configure itself correctly.
Change-Id: I80d1ea7a7704666027e74228036af5e0e4b9eac2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27218
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
As we are now going to maintain different bundles of resources for each
gem5 release, the resources have been archived to
http://dist.gem5.org/dist/current for gem5 19. The development branch
will use http://dist.gem5.org/dist/develop going forward. New releases
will follow the format http://dist.gem5.org/dist/{VERSION}.
This patch makes the resources url a command-line parameter, set to the
"correct" url by default. This will be updated to the correct, archived,
version subdirectory upon release of a new gem5 version. E.g.:
http://dist.gem5.org/dist/v20 for the gem5 20 release.
Some Make files have been cleaned up to no longer fetch and push to
remote locations. As gem5-resources is implemented, sources will be
moved to the gem5-resources resository and compiled binaries, etc.
pulled from our Google Cloud bucket from the tests themselves.
Change-Id: Ia16c496be3a60283ecc431ffaa5b059e1932b526
Issue-on: https://gem5.atlassian.net/browse/GEM5-431
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27987
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 Patch will fix the alignment problem that appears sometimes
when we try to create a view of 128 bits over the VecRegContainer
object.
That container is initially created as std::array<uint8_t, SIZE>, so
there is no obligation to be aligned to 16 bytes. This patches forces
all containers to be aligned to 16 bytes.
The problem has been observed in the Jira Issue:
https://gem5.atlassian.net/browse/GEM5-320
Change-Id: Id9fdd427bd7a4dc904edd519f31cc29c5b29c5e6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27968
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch addresses multiple cases:
- When a controller has read/write permissions while others have read
only permissions, the one with r/w permissions performs the read as
the others may have stale data
- When controllers only have lines with stale or busy access permissions,
a valid copy of the line may be in a message in transit in the network
or in a message buffer (not seen by the controller yet). In this case,
we forward the functional request accordingly.
- Sequencer messages should not accept functional reads
- Functional writes also update the packet data on the sequencer
outstanding request lists and the cpu-side response queue.
Change-Id: I6b0656f1a2b81d41bdcf6c783dfa522a77393981
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22022
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: John Alsop <johnathan.alsop@amd.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.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>
This is specialized per arch, and the Workload class is the only thing
actually using it. It doesn't make any sense to dispatch those calls
over to the System object, especially since that was, in most cases,
the only reason an ISA specific system class even still existed.
After this change, only ARM still has an architecture specific System
class.
Change-Id: I81b6c4db14b612bff8840157cfc56393370095e2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24287
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This generalized Workload SimObject is not geared towards FS or SE
simulations, although currently it's only used in FS. This gets rid
of the ARM specific highestELIs64 property (from the workload, not the
system) and replaces it with a generic getArch.
The old globally accessible kernel symtab has been replaced with a
symtab accessor which takes a ThreadContext *. The parameter isn't used
for anything for now, but in cases where there might be multiple
symbol tables to choose from (kernel vs. current user space?) the
method will now be able to distinguish which to use. This also makes
it possible for the workload to manage its symbol table with whatever
policy makes sense for it.
That method returns a const SymbolTable * since most of the time the
symbol table doesn't need to be modified. In the one case where an
external entity needs to modify the table, two pseudo instructions,
the table to modify isn't necessarily the one that's currently active.
For instance, the pseudo instruction will likely execute in user space,
but might be intended to add a symbol to the kernel in case something
like a module was loaded.
To support that usage, the workload has a generic "insertSymbol" method
which will insert the symbol in the table that "makes sense". There is
a lot of ambiguity what that means, but it's no less ambiguous than
today where we're only saved by the fact that there is generally only
one active symbol table to worry about.
This change also introduces a KernelWorkload SimObject class which
inherits from Workload and adds in kernel related members for cases
where the kernel is specified in the config and loaded by gem5 itself.
That's the common case, but the base Workload class would be used
directly when, for instance, doing a baremetal simulation or if the
kernel is loaded by software within the simulation as is the case for
SPARC FS.
Because a given architecture specific workload class needs to inherit
from either Workload or KernelWorkload, this change removes the
ability to boot ARM without a kernel. This ability should be restored
in the future.
To make having or not having a kernel more flexible, the kernel
specific members of the KernelWorkload should be factored out into
their own object which can then be attached to a workload through a
(potentially unused) property rather than inheritance.
Change-Id: Idf72615260266d7b4478d20d4035ed5a1e7aa241
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24283
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
