Hi Marcelo,
For future reference, if someone else has this issue... Another possibility
is that the branch predictor is the problem. It looks like it could be
predicting that instruction is a branch. I'm not sure if it's specifically
because of the compressed format or not, though. It's another
Hi Jason, Alec,
Just to provide some feedback on this issue, it seems that the processor is
mistakenly identifying (add reg, reg, reg) in compressed format as a branch
instruction.
I'm running a kernel that looks like this (result from
*riscv64-unknown-elf-objdump
-D*)
0001019a :
Hi Jason, Alec,
Thanks for the fast responses!
I can say I managed to run a lot of benchmarks on O3 and none of them
crashed. I did notice however that their performance on for distinct-width
O3 processors had only minor differences (on x86, the differences were much
more significant).
I ran
Hi Marcelo,
Yes, gem5 does support the C extension (64-bit version only, though). I
don't know what could be causing your particular issue. I'm not sure
advancePC is the issue, though, because all that essentially does is call
PCState::advance(), which is inherited unchanged from
Hi Marcelo,
I'm not sure if RISC-V has been tested with the out of order CPU at all!
I'm happy that at least it doesn't completely fail!
For you problem of only fetching 1 instruction per cycle... I think it's
going to take some digging. My first guess would be that it could be a
problem with
Hi all,
I recently switched from gem5/x86 to gem5/RISCV due to some advantages of
this ISA.
I'm getting some weird simulation results and I realized my compiler was
generating instructions for the compressed RISCV ISA extension (chp 12 in
the user level ISA specification
