Is there a tool in AS7 or MPLABX (or elsewhere) that will take analyze best and worst-case execution time for an AVR function?
(How about one that measures code over a large number of simulated executions?)
Is there a tool in AS7 or MPLABX (or elsewhere) that will take analyze best and worst-case execution time for an AVR function?
(How about one that measures code over a large number of simulated executions?)
And if I use the gdb avr "target sim" simulator, how come "info target" shows a cycle count:
(gdb) info target
Symbols from "/private/tmp/time.elf".
simulator:
Attached to sim running program /private/tmp/time.elf
# cycles 190
but $cycles doesn't seem to be available?
(gdb) show convenience
$cycles = void
$bpnum = 1
(or elsewhere)
(How about one that measures code over a large number of simulated executions?)
...
What’s it for?
PathCrawler’s principal functionality is to automate structural unit testing by generating test inputs which cover all the feasible execution paths of the C function under test.
...
The path tests generated by PathCrawler can also be used to measure the effective execution time of an uninterrupted task in a real-time application, and get an accurate estimate of the longest execution time.
Can I try it?
[trial - web app, evaluation - executable via NDA]
...
A brief introduction to fuzzing and why it’s an important tool for developers - Microsoft Research
Doesn't seem to handle asm (or have avr-specific results.)
I want to compare some C code to a "suggested replacement" ASM code.
handle asm
For real time, -and may be simulated, too- I am using a spare timer. If the clock is 8M, then timer divisor is 8, and the resolution is 1us. TimeEnd - TimeBegin may be 8-bit, or 16-bit /if that long/.
Is the code tied to hardware? If it was just an algorithm - maybe something like JPEG decode say - then one approach is to build it for x86 and then use valgrind + kcahegrind which is an amazing set of tools for analyzing code performance and there the "bottle-necks" that would really benefit from concentrated rewrite/optimization. We use it for profiling CPU bound video processing code.
But the point is that valgrind actually works by simulating the CPU (well it uses a virtual machine) so it can intercept and log all the instruction fetches. To do something similar for an AVR it would have to be based around an AVR simulator but one that has hooks to log the instruction fetches. They can then (via the DWARF) be traced back to which file, function, line they are related to so a picture of where the code is spending most of its time can be built up.
To do something similar for an AVR it would have to be based around an AVR simulator but one that has hooks to log the instruction fetches.
AVR System emulator — QEMU 6.0.90 documentation
[bottom]
Print out executed instructions (that have not been translated by the JIT compiler yet):
Here is my list of free simulators. Most of them don't handle avr-0.
+ https://github.com/buserror/simavr
+ https://www.nongnu.org/simulavr/
+ https://github.com/ghewgill/emul...
+ http://www.avr-asm-tutorial.net/...
+ https://github.com/Milo-D/libvmc...
Most of them don't handle
In the case of KcaheGrind you can then get "heatmaps" like this:
which can highlight the "big hitters". Also it can map out a call hierarchy..
with % values saying how much of the time was spent beneath certain functions etc etc.
(it's very powerful!)
But the point is that valgrind actually works by simulating the CPU (well it uses a virtual machine) so it can intercept and log all the instruction fetches. To do something similar for an AVR it would have to be based around an AVR simulator but one that has hooks to log the instruction fetches. They can then (via the DWARF) be traced back to which file, function, line they are related to so a picture of where the code is spending most of its time can be built up.
I have written an extension tool for valgrind to estimate CPU utilization. It does not handle caching and you have to fill out a table cycle counts for each VEX instruction, but I think it can be useful.