- Change polarity of svukte_qualified to match ISA spec
- Avoid address dependence of svukte_qualified, per ISA spec
- Move address check to separate routine
Based on section 18.2 in spec
"All Zve* extensions support all vector integer instructions (Section
Vector Integer Arithmetic Instructions), except that the vmulh integer
multiply variants that return the high word of the product (vmulh.vv,
vmulh.vx, vmulhu.vv, vmulhu.vx, vmulhsu.vv, vmulhsu.vx) are not
included for EEW=64 in Zve64*."
"All Zve* extensions support all vector fixed-point arithmetic
instructions (Vector Fixed-Point Arithmetic Instructions), except that
vsmul.vv and vsmul.vx are not included in EEW=64 in Zve64*"
Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com>
Based on spec
section 18.4
"The Zvfhmin extension depends on the Zve32f extension."
section 18.5,
"The Zvfh extension depends on the Zve32f and Zfhmin extensions."
Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com>
In privilege spec sec 3.1.18
" The Ssdbltrp extension adds the double-trap-enable ( DTE ) field in
menvcfg . When menvcfg.DTE is zero, the implementation behaves as
though Ssdbltrp is not implemented. When Ssdbltrp is not implemented
sstatus.SDT , vsstatus.SDT , and henvcfg.DTE bits are read-only zero."
The change keep the mstatus.sdt unchangedable and always read-as-zero
when menvcfg.dte is cleared
Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com>
vfncvtbf16_f_f_w and vfwcvtbf16_f_f_v only depend on
Zvfbf16min but not Zvfbfa
ref:
https://github.com/aswaterman/riscv-misc/blob/main/isa/zvfbfa.adoc
"
vfwcvtbf16.f.f.v † (only if Zvfbfmin is implemented)
vfncvtbf16.f.f.w † (only if Zvfbfmin is implemented)
The instructions marked with † have the same semantics regardless of altfmt
"
Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com>
`pmp_ok` needs to handle misaligned addresses and non-power-of-2 lengths,
so round them before checking the PMPs.
As an optimization, reduce the number of PMP checks based upon the PMP
granularity.
Dataflow through the PC is an ILP bottleneck. Reduce the critical code path
by memoizing the likely next PC.
The first time an instruction is cached, the assumption is that the likely
next PC is on the sequential path. Whenever the instruction is executed and
the next PC was mispredicted, correct it. This does the right thing for
jumps and heavily biased branches. The misprediction penalty is low enough
that doing something smarter for less-biased branches is unprofitable.
Andrew Waterman
Binno
Chih-Min Chao
Alexander Romanov
steven
Nadime Barhoumi
Zhibo Hong