Feature Request: Chronometer Overhead Adjustment

Sysprogs forums Forums VisualGDB Feature Request: Chronometer Overhead Adjustment

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #29649
    hopperpl
    Participant

    the Chronometer is an excellent feature, it works pleasingly well and accurate…

    for assembler code (ARM Cortex M7), I get a clock cycle delta of 12-15 cycles per instruction and I pinned that down to an exact (really exact) overhead of 11 cycles per single step… which gives me a precise instruction delta of 12-11=1 or 13-11=2 cycles per instruction. It fits so well, I can see the delta timing of instructions that need multiple cycles to execute. Theory (reference manual) vs Reality just fits. I just need to subtract the 11-cycle overhead for each single-step, so it would be great if settings had an option so set the overhead per single-step command, which then gets automatically subtracted… how to get the 11 cycles? well, that’s my job to determine this value. And it’s actually not hard… single step in the disassembler window and use the minimum value you see, minus 1 for the actual instruction execution.

    I also noticed for conditional instructions, that the timing jumps to 24 cycles. I omit the if-then intrinsic (“it”) as gas assembler generates those for me. I’m not sure, but I assume that VisualGDB issues multiple single-step commands (2 here) to gdb to catch up with the source file, instead of using a temporary hardware breakpoint. If that’s the case, it just highlights the accurate of this feature 11+1+11+1=24.

    So, an overhead adjustment (with accounting for multiple single-steps internally) would be fantastic.

    #29660
    support
    Keymaster

    Hi,

    Fully compensating for the single-step overhead could be trickier that it may seem, as the overhead would depend on the internal implementation of the debug stub (e.g. OpenOCD) and may vary between different cores and things like interrupt level. Also events like skipped conditional breakpoints would considerably skew it.

    The main use case for Chronometer is comparing different versions of the code, or different code paths. As the same overhead is added to both compared options, it will not affect the difference between them, and the effect of it on the relative difference will be negligible in most cases.

    Either way, the Chronometer rules are stored in <VisualGDB directory>\TickCountExpression\DWT.xml file. You can subtract any arbitrary constant from the TickCountExpression to achieve the effect you described (since TickCountResetCondition is 1, the tick counter is always reset after it has been queried).

Viewing 2 posts - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.