Cortex-A53 ：The execution time of the same four assembly code instructions varies at different locations（non-cacheable）. After counting with the PMU, it is found that in the slower cases, there is an additional instruction per cycle.If the instruction cache is enabled, the runtime will be consistent. Please analyze the reasons for this
Is it related to dual-issue instruction？
Is your sequence something like:
start: Read PMU Cycle Count INSTR1 INSTR2 INSTR3 INSTR4 Read PMU Cycle Count B start
If so, I suspect part of the problem is that the sequence (4 assembly instructions) is too short to accurately measure this way. The issue is that with such a short sequence the noise introduced by reading the PMU, branching, prefetch, etc... will be comparatively large relative to what you're trying to measure. Hence the noisy result.
More typically I'd expect something like this:
MOV x0, num_loops Read PMU Cycle Countstart: INSTR1 INSTR2 INSTR3 INSTR4 SUB x0, x0, 1 CBNZ start Read PMU Cycle Count
That is, run the sequence many times and average the result.
We used Lauterbach Trace32 to view the PMU；The initialization time difference between two 40Mbytes BSS segments is 1 second.
It's a long time since I last used the Lauterbach tools, so I can't comment specifically on them. However, if you're doing this in a debugger I'd expect it to make the effects I talked about worse. Every time you set or hit a breakpoint the debugger is (typically) going to do a bunch of interactions with the target - for example to populate memory or register views. Even if it doesn't, the act of entering/exiting debug state is going to muddy the numbers you see.
If you want to measure an instruction sequence using the PMU I think you'll need to follow the above suggestion. Run the sequence many time in a loop, reading the PMU only at the start and end, then averaging over the number of iterations. Without interacting with the debugger for the duration of the loop.