Disassembly view (next to code) NOT in debug mode

[Ricko]

Hi,

I want to compare a couple of different ways to implement the same functionality in an ISR to see which one leads to the smallest/fastest code.

Is there a way - after compiling but without running a debug session - to see the disassembly code after each instruction?

Also - regardless of whether there is such way or not - what other ways can you see the number of cycles it takes for a chunk of code to execute, again, without running a debug session on the micro.

Thank you

[TDK · Accepted solution]

> Is there a way - after compiling but without running a debug session - to see the disassembly code after each instruction?

Add a post-build step to create the listing file:

After building, you can then open this file to view the disassembly.

[TDK]

> Also - regardless of whether there is such way or not - what other ways can you see the number of cycles it takes for a chunk of code to execute, again, without running a debug session on the micro.

There's no way to do this in general, especially for more complicated cores. For example, the number of cycles per instruction is not constant for the M7 core as it tries to pipeline instructions and do delayed writes where possible. There are many other factors that complicate this calculation, including flash wait states, cache hits/misses, internal bus activity.

[Tesla DeLorean]

ARM might have some advanced simulation/estimation tools, that can look at the throughput, and what code has pipeline dependencies. Probably some static analysis tools out there if you have a budget for them. Thing's like ARM's trace does flow analysis and reconstruction from "hints" that it records.

For things like the 68000/68020 I built disassemblers that provided instruction times, and Microsoft's MASM 6.xx used to be able to add estimates to the line listings.

You could perhaps run the listing through a script, using AWK or PERL, or whatever you're skilled in, and add estimations, timing of branches taken/not-taken, identify aligned branch targets, cross-reference things.

Identify the handful of more complex instructions MUL / DIV/ LDM / STM which contribute more/variable cycles. Or summing up potential times from different subroutines. Some tools will provide call-trees and stack analysis.

[Ricko]

Thank you @Tesla DeLorean