The CL updates the Kconfig:
1. Replace the USE_NULL_ISA with BUILD_ISA
2. The USE_XXX_ISAs are depends on BUILD_ISA
3. If the BUILD_ISA is set, at least one of USE_XXX_ISAs must be set
4. Refactor the USE_KVM option
Change-Id: I2a600dea9fb671263b0191c46c5790ebbe91a7b8
The TARGET_ISA variable would let you select one ISA from a list of
possible ISAs. That has now been replaced with USE_ARM_ISA, USE_X86_ISA,
etc, variables which are boolean on or off. That will allow any number
of ISAs to be enabled or disabled individually. Enabling something other
than exactly one of these will probably prevent you from getting a
working gem5 binary, but those problems are being addressed in other,
parallel change series.
I decided to use the USE_ prefix since it was consistent with most other
on/off variables we have in gem5. One noteable exception is the
BUILD_GPU setting which, you could convincingly argue, is a better
prefix than USE_. Another option would be to use CONFIG_, in
anticipation of using a kconfig style config mechanism in gem5.
It seemed premature to start using a CONFIG_ prefix here, and if we
decide to switch to some other prefix like BUILD_, it should be a
purposeful choice and not something somebody just starts using.
Change-Id: I90fef2835aa4712782e6c1313fbf564d0ed45538
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52491
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This makes what are configuration and what are internal SCons variables
explicit and separate, and makes it unnecessary to call out what
variables to export to C++.
These variables will also be plumbed into and out of kconfiglib in later
changes.
Change-Id: Iaf5e098d7404af06285c421dbdf8ef4171b3f001
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56892
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The recent change to add an "exclude" pattern to Glob in SCons also
seems to have triggered a bug where SCons has decided directories that
don't exist are files, and then gets upset later when we try to treat
them as directories.
To avoid that bug, and to also make recursive searching for isa parser
.py files work, we can replace the call to Glob with a loop based on
os.walk.
Also, tell the microcode assembler not to generate the parsetab.py file
in the first place. This comes with a minor performance overhead, but
shouldn't matter for us since there are *much* bigger overheads when
processing ISA descriptions.
Change-Id: Ia84e97dab72723ad3f4350798ad70178e231144c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56749
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Because we don't have a good way to actually figure out what python
files we depend on, we have to use Glob and wildcard matching to depend
on all potential python files. Unfortunately that will pick up the
parsetab.py file that ply generates, which is a cached intermediate file
and not an input.
Change-Id: Id3dc0083e97c145deca04939182157623d6b780f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56341
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
The arch implies gem5 lib, and not the other way around. Or in other
words, if, for example, x86 is the ISA, the having the tag 'x86 isa'
would imply that that file also has the tag 'gem5 lib'. Having the tag
'gem5 lib' would not imply 'x86 isa'.
This worked out because when testing for a single tag, we were using
with_any_tags, and 'gem5 lib' would expand to 'gem5 lib' and 'x86 isa'.
Then we would match files which were non-specific and used 'gem5 lib',
or files which had more specifically used 'x86 isa' only. Files which
used, for instance, 'arm isa', would not meet either criteria of the
implied "or".
Change-Id: I301d1bbbbcac1594371584d4b0d5d291b7b77fc4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51827
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
Otherwise, SCons may discover an include which is guarded with BUILD_GPU
(like GPUCoalescer in mem/ruby/profiler/Profiler.cc), but not understand
that BUILD_GPU is not true. It will then follow the includes and find
generated headers which it will then generate, specifically X86 headers
for X86TLB and X86Pagetable param structs.
If not using x86, for instance if building the NULL isa, it may not be
possible to generate those headers because those objects are not visible
to SCons.
Change-Id: I955d0ef6ffb146eeb99bb052d29abe835cac5d9a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51829
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Turn the functions within it into virtual methods on the ISA classes.
Eliminate the implementation in MIPS, which was just copy pasted from
Alpha long ago. Fix some minor style issues in ARM. Remove templating.
Switch from using an "XC" type parameter to using the ThreadContext *
installed in all ISA classes.
The ARM version of these functions actually depend on the ExecContext
delaying writes to MiscRegs to work correctly. More insiduously than
that, they also depend on the conicidental ThreadContext like
availability of certain functions like contextId and getCpuPtr which
come from the class which happened to implement the type passed into XC.
To accomodate that, those functions need both a real ThreadContext, and
another object which is either an ExecContext or a ThreadContext
depending on how the method is called.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1053
Change-Id: I68f95f7283f831776ba76bc5481bfffd18211bc4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50087
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Now all occurances of the THE_ISA macro which were being used to check
for anything other than the NULL_ISA have been eliminated. We still need
to be able to check whether the current ISA is the null ISA, but we
don't want to let any preprocessor checks back in which are based on
what the current ISA is.
This change removes the THE_ISA macro, and replaces it with IS_NULL_ISA
which evaluates to 1 if the ISA is null, and 0 if it isn't.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1060
Change-Id: Iec146b40d8cab846dae03e15191390f754f2b71b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48709
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The only thing brought in by arch/types.hh is TheISA::PCState. Instead
of having the other types around where they could be used accidentally,
and to make it more obvious what's being exported, this change splits
PCState out into a new switching header called arch/pcstate.hh. The
original arch/types.hh is no longer a switching header, and includes
pcstate.hh.
Change-Id: I8dfd298349e4565f316f7b9a028703289ada6010
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40177
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
This flag was necessary because of self assignments in the ISA parser
where self assignments are often hints to the parser itself, and in one
case because a pybind-ism used to attach the -= operator looked like a
self assignment.
This change narrows the scope of the flag that disables this warning to
only files generated by the ISA parser, and the single file in the
systemc code which uses that operator overload.
Change-Id: Ib64fc72e46f894cba9064afcdbdcc5859c30e745
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40952
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.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>
The event in KVM x86 SE mode plays double duty, triggering a system call
or a page fault depending on where it's called from (the system call
handler vs page fault handler).
This means we can eliminate the page fault gem5 op and the
pseudo_inst.hh switching header file.
This change touches a lot of things, but there wasn't really a good
place to split it up which still made sense and was consistent and
functional.
Change-Id: Ic414829917bcbd421893aa6c89d78273e4926b78
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34165
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This function is no longer used anywhere in gem5.
Small helper functions which had been put alongside vtophys on ARM and
RISCV were also moved into src/arch/arm/remote_gdb.cc and
src/arch/power/pagetable.hh, the only places they were used.
Change-Id: Iba72f6c4b797a35a785a5bb781d602c943541fa7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26234
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The new local access mechanism installs a callback in the request which
implements what the mmapped IPR was doing. That avoids having to have
stubs in ISAs that don't have mmapped IPRs, avoids having to encode
what to do to communicate from the TLB and the mmapped IPR functions,
and gets rid of another global ISA interface function and header files.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: I772c2ae2ca3830a4486919ce9804560c0f2d596a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23188
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Latest-gen. vector/SIMD extensions, including the Arm Scalable Vector
Extension (SVE), introduce the notion of a predicate register file.
This changeset adds this feature across architectures and CPU models.
Change-Id: Iebcadbad89c0a582ff8b1b70de353305db603946
Signed-off-by: Giacomo Gabrielli <giacomo.gabrielli@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/13715
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.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>
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
Factor out the ISA ness of the switching header generating function. Also
turn it into a SCons builder which builds a single header, and a wrapping
method which uses the builder on a group of header files which all target
the same subdirectory.
Change-Id: I87705f97b6ebd9baebd4ebcfea19cc1218a64ad0
Reviewed-on: https://gem5-review.googlesource.com/2983
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
the GPUISA class is meant to encapsulate any ISA-specific behavior - special
register accesses, isa-specific WF/kernel state, etc. - in a generic enough
way so that it may be used in ISA-agnostic code.
gpu-compute: use the GPUISA object to advance the PC
the GPU model treats the PC as a pointer to individual instruction objects -
which are store in a contiguous array - and not a byte address to be fetched
from the real memory system. this is ok for HSAIL because all instructions
are considered by the model to be the same size.
in machine ISA, however, instructions may be 32b or 64b, and branches are
calculated by advancing the PC by the number of words (4 byte chunks) it
needs to advance in the real instruction stream. because of this there is
a mismatch between the PC we use to index into the instruction array, and
the actual byte address PC the ISA expects. here we move the PC advance
calculation to the ISA so that differences in the instrucion sizes may be
accounted for in generic way.
