cancel
Showing results for 
Search instead for 
Did you mean: 

Disassembly view (next to code) NOT in debug mode

Ricko
Senior II

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

1 ACCEPTED SOLUTION

Accepted Solutions
TDK
Guru

> 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:

TDK_0-1723921187158.png

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

TDK_1-1723921232516.png

 

If you feel a post has answered your question, please click "Accept as Solution".

View solution in original post

4 REPLIES 4
TDK
Guru

> 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:

TDK_0-1723921187158.png

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

TDK_1-1723921232516.png

 

If you feel a post has answered your question, please click "Accept as Solution".
TDK
Guru

> 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.

If you feel a post has answered your question, please click "Accept as Solution".

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Thank you @Tesla DeLorean