Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redundant Load and Branch Instructions from HTIF while executing binaries #314

Open
RRavikiran66 opened this issue Jan 31, 2024 · 3 comments

Comments

@RRavikiran66
Copy link

When executing the MIbench/telecomm/crc benchmark or any other benchmark in Mibench on the RISC-V ISA simulator (Spike), the execution log shows a repetitive pattern of two identical instructions, specifically load and branch instructions. It is observed that these instructions are originating from HTIF (Host-Target Interface) and not from the ELF file being executed. I have tried to trace it down I found that this pattern begins from mret and continues till sret. So, the Spike enters the machine mode to supervisor mode because of a trap but how can we avoid this? Or it's just the part of Spike.

Questions:
Expected Behavior: Is the repetition of identical load and branch instructions from HTIF expected behavior in the Spike simulator when running the MIbench benchmark?

Mitigation: How can these redundant load and branch instructions from HTIF be avoided in order to improve the accuracy and efficiency of the simulation? Are there specific configurations or settings that need to be adjusted?

Environment:
Host Operating System: Fedora workstation 37
Target Architecture: RISC-V
Benchmark: MIbench/telecomm/crc

Additional Information: I have generated the log, below is a small part of the log(I get the same pattern for millions of iterations):

core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4`

Thank you for your assistance in addressing this issue.

@jerryz123
Copy link

PK uses the HTIF interface for syscalls. The HTIF interface is through polling reads and writes to special memory addresses (tohost/fromhost). You are likely seeing polling on fromhost due to some syscalls from your target benchmark.

If you are evaluating some benchmark using PK, you must be careful that there are no syscalls in the region of interest in the benchmark.

@RRavikiran66
Copy link
Author

Thanks a lot for your reply, For that, I have marked the whole PK as a junkROI and If I'm inside the PK(i.e- Junk Region in my case) I don't update the stats or trace. Even with this, I see a lot of Instructions that are not from the binary that I'm executing. Is there a way to get PC(IP) in the trace that is only in the binary that I'm executing?

@sawansib
Copy link

Hello @jerryz123 ,

I've observed a comparable trace as well. I suspect this occurs for any trap involving syscalls. The behavior is consistent even when running a complete Linux environment on Spike. Given that the Linux setup is expected to support all syscalls, could this behavior occur due to other traps, like misaligned memory access?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants