Current hardcoded value does not support vector instructions.
The new ISA string generator function allows the flexibility
of using or not using the vector extension.
Change-Id: Ic78c4b6629ad3813fc172f700d77ea956552e613
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
Currently, we are hardcoding the ISA string in the device tree
generator. The ISA string from the device tree affects which
ISA extensions will be used by the bootloader/kernel.
This function allows generating the ISA string from the gem5's
ISA object rather than using hardcoded values.
Change-Id: I2f3720fb6da24347f38f26d9a49939484b11d3bb
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
Major refactoring of the branch predictor unit.
- Clearer control flow of the main branch predictor
- Remove `uncondBranch` and `btbUpdate` functions in favour of a
common `historyUpdate` function. There is now only one lookup
function for conditional branches and the new `historyUpdate` for
speculative history update.
- Added a new *target provider* class.
- More expressive statistics depending on the different branch types.
- Cleanup the branch history management
Change-Id: I21fa555b5663e4abad7c836fc1d41a9c8b205263
Signed-off-by: David Schall <david.schall@ed.ac.uk>
Some debug registers were incorrectly tagged
(e.g. as being writeable). This was causing a bug in some gem5-KVM runs
where gem5 was trying to initialize the state of those registers
(OSLSR_EL1) [1] but KVM was returning an error (as the registers were
RO).
[1]: https://github.com/gem5/gem5/blob/stable/\
src/arch/arm/kvm/armv8_cpu.cc#L408
Capstone is an open source disassembler [1] already used by
other projects (like QEMU).
gem5 is already capable of disassembling instructions. Every StaticInst
is supposed to define a generateDisassembly method which returns the
instruction mnemonic (opcode + operand list) as a string.
This "distributed" implementation of a disassembler relies
on the developer to properly populate the metadata fields
of the base instruction class.
The growing complexity of the ISA code and the massive reuse
of base classes beyond their intended use has led to a
disassembling logic which contains several bugs.
By allowing a tracer to rely on a third party disassembler, we fill the
instruction trace with a more trustworthy instruction stream.
This will make any trace parsing tool to work better and it will
also allow us to spot/fix our own bugs by comparing instruction
traces with native vs custom disassembler
[1]: http://www.capstone-engine.org/
Capstone is an open source disassembler [1] already used by
other projects (like QEMU).
gem5 is already capable of disassembling instructions. Every StaticInst
is supposed to define a generateDisassembly method which returns the
instruction mnemonic (opcode + operand list) as a string.
This "distributed" implementation of a disassembler relies
on the developer to properly populate the metadata fields
of the base instruction class.
The growing complexity of the ISA code and the massive reuse
of base classes beyond their intended use has led to a
disassembling logic which contains several bugs.
By allowing a tracer to rely on a third party disassembler, we fill the
intruction trace with a more trustworthy instruction stream.
This will make any trace parsing tool to work better and it will
also allow us to spot/fix our own bugs by comparing instruction
traces with native vs custom disassembler
[1]: http://www.capstone-engine.org/
Change-Id: I3c4db5072c03d2731265d0398d3863c101dcb180
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
We move it to the child class which is what the TarmacTracer
actually uses.
Change-Id: Ia30892723d2e1f7306dae87c6c9c1d69d00ad73d
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
We want to be able to configure from python the disassembler
used by an instruction tracer. The default/base version will
reuse existing instruction logic and it will simply
call the StaticInst::disassemble method.
Change-Id: Ieb16f059a436757c5892dcc82882f6d42090927f
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Currently the type of HAVE_DEPRECATED_NAMESPACE is used to detect
if the compiler support gnu::deprecated feature. The return type
of conf.TryCompile is int, but HAVE_DEPRECATED_NAMESPACE is used
as boolean type. The CL is add bool type caster to ensure the type
of it is boolean.
Change-Id: Ife7d9716e485a8be8722d58776f064e7c2268a30
This patch fixes the size of the memory acceses in vswhole and
vlwhole instructions to the maximum vector length.
Change-Id: Ib86b5356d9f1dfa277cb4b367893e3b08242f93e
This patch adds elen as a member of vector configuration instructions so it can be used with the especulative execution
Change-Id: Iaf79015717a006374c5198aaa36e050edde40cee
In first place, vlen is added as a member of Vector Macro Instructions
where it is needed to split the instruction in Micro Instructions.
Then, new PCState methods are used to get dynamic vlen and vlenb
values at execution.
Finally, vector length data types are fixed to 32 bits so every vlen value
is considered.
Change-Id: I5b8ceb0d291f456a30a4b0ae2f58601231d33a7a
This patch add vlen definition to the riscv decoder so it can be used in Vector Instruction Constructors
Change-Id: I52292bc261c43562b690062b16d2b323675c2fe0
This path redefine VecRegContainer for RISCV so it can hold every VLEN + ELEN possible configuration used at execution time
Change-Id: Ie6abd01a1c4ebe9aae3d93f4e835fcfdc4a82dcd
Misc Regs might contain rather important information about the state of
a core, e.g., information in CSR registers.
This patch enforces copying the CSR registers when switching cpus. The
bug and the proposed fix are reported here [1].
[1] https://github.com/gem5/gem5/issues/451
Change-Id: I611782e6e3bcd5530ddac346342a9e0e44b0f757
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
The return address stack (RAS) is restructured to be a separate SimObject.
This enables disabling the RAS and better separation of the functionality.
Furthermore, easier statistics and debugging.
Change-Id: I8aacf7d4c8e308165d0e7e15bc5a5d0df77f8192
Signed-off-by: David Schall <david.schall@ed.ac.uk>
This is similar to [1] and [2].
Essentially, the VS bits of STATUS CSR keep track of the state of
the vector registers. (VS bits == DIRTY) means the content of vector
registers have been updated since the last time the VS bits were
updated.
This chain of changes is supposed to change the VS bits to DIRTY for if
any
vector register is potentially updated.
[1] https://gem5-review.googlesource.com/c/public/gem5/+/65272
[2] https://github.com/gem5/gem5/pull/370
Change-Id: I0427890dadc63b74a470d7405807dcfcad18005b
In commit bbc301f2f0 the generalized
`Exception` was changed back to the more specific `HTTPError`.
In this case we do not desire specific error handling. If the connection
to the database fails I want the exception handled in the way outlined:
i.e., i want the connection to be retried 4 times before giving up. With
`HTTPError`, only `HTTPError`s warrent a retry.
Changing this to `HTTPError` cause tests to fail due to a failure to
retry downloading of a resource. Here is an example:
https://github.com/gem5/gem5/actions/runs/6521543885/job/17710779784
In this case `request.urlopen` raised a `URLError`. I suspect this was
some issued to do with reaching the DNS servers. It likely would've
succeeded if it had just tried again.
This only applies to pseudo instructions with their own encoding (m5
ops)... In other
words memory mapped m5 operations are not supported. This make sense as
they should
rather be treated as device accesses... Though it is something to take
into consideration
when relying on the flag
While it's plausible to define the cache_line_size as a 32-bit unsigned
int, the use of cache_line_size is way out of its original scope.
cache_line_size has been used to produce an address mask, which masking
out the offset bits from an address. For example, [1], [2], [3], and
[4]. However, since the cache_line_size is an "unsigned int", the type
of the value is not guaranteed to be 64-bit long. Subsequently, the bit
twiddling hacks in [1], [2], [3], and [4] produce 32-bit mask, i.e.,
0x00000000FFFFFFC0.
This behavior at least caused a problem in LLSC in RISC-V [5], where the
load reservation (LR) relies on the mask to produce the cache block
address. Two distinct 64-bit addresses can be mapped to the same cache
block using the above mask.
This patch explicitly defines cache_line_size as a 64-bit unsigned int
so the cache block mask can be produced correctly for 64-bit addresses.
[1]
3bdcfd6f7a/src/cpu/simple/atomic.hh (L147)
[2]
3bdcfd6f7a/src/cpu/simple/timing.hh (L224)
[3]
3bdcfd6f7a/src/cpu/o3/lsq_unit.cc (L241)
[4]
3bdcfd6f7a/src/cpu/minor/lsq.cc (L1425)
[5]
3bdcfd6f7a/src/arch/riscv/isa.cc (L787)
Being able to recognise pseudo ops from the static instruction
pointer is actually quite useful in several circumstances
Change-Id: Ib39badf9aabba15ab3ebe7a8e9717583412731e4
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
With -m, you can now run a module from the command line that is embedded
in the gem5 binary.
This will allow us to put some common "scripts" in the stdlib instead of
in the "configs" directory.
Added checks to ensure that atomics are not performed in the TCC when it
is configured as a write-through cache. Also added SLC bit overwrite to
ensure directory preforms atomics when there is a write-through TCC.
Change-Id: I4514e6c8022aeb7785f2c59871cd9acec8161ed8
After removing the setRegOperand in VecRegOperand
https://github.com/gem5/gem5/pull/341. The vmask_vm_micro will not write
back to register because tmp_d0 is not the reference type. The PR will
make tmp_d0 as reference of regFile.
Change-Id: I2a934ad28045ac63950d4e2ed3eecc4a7d137919
This PR updates cache recorder to use a vector of RubyPorts for cache
cooldown and warmup instead of Sequencer or GPUCoalescer vectors (refer
to issue #403 for more details). It also removes the extra guards that
were added in #377 to prevent compile-time failures in non-GPU builds.
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>
Jazelle state has been officially removed in Armv8.
Every AArch32 implementation must still support the
"Trivial Jazelle implementation", which means that while
the instruction set has been removed, it is still possible
for privileged software to access some Jazelle registers
like JIDR,JMCR, and JOSCR which are just treated as RAZ
Change-Id: Ie403c4f004968eb4cb45fa51067178a550726c87
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
A previous commit added BUILD_GPU guards to gpu coalescer models since
a related cache recorder commit added GPU support. This is no longer
needed since the cache recorder moved to using a vector of RubyPorts
instead of Sequencer/GPUCoalescer pointers. This commit removes
BUILD_GPU guards from the Ruby coalescer models
Change-Id: I23a7957d82524d6cd3483d22edfb35ac51796eca
Previously, the cache recorder used a vector of sequencer pointers to
access Ruby objects. A recent commit updated the cache recorder to also
maintain a vector of GPUCoalescer pointers in order for GPUs to support
flushin. This added redundant code to the cache recorder. This commit
replaces the sequencer and GPUCoalescer vectors with a vector of
RubyPort pointers so that the code does not contain redundant lines
Change-Id: Id5da33fb870f17bb9daef816cc43c0bcd70a8706
