Re: [hatari-devel] Hatari profiler updates and CPU cycle questions

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On torstai 31 tammikuu 2013, Douglas Little wrote:
> *For Eero: With DSP profiling I think it would be extra useful for the
> profiler to indicate 'fractional' cycle timings for opcodes where the
> 'average' is not a constant (i.e. not an integer). e.g if the timing of
> an instruction varies between  2 and 3, it may read '2.2' or suchlike.
> **Otherwise (perhaps better) indicate those unstable timings with a
> special symbol at the end of the line - so a user can tell when an
> instruction has a variable cost at runtime (that is quite interesting
> information from an optimisation point of view :-) *

For DSP I could store (in addition of sum of instructions & cycles)
also min and max cycle values for individual addresses.  Disassembly
could them contain those, or just indicator that they differed.
Would that be enough?

For CPU profiling, storing extra information per memory address would
take too much memory because there can be 14MB of addresses (so just
the 32-bit instruction count takes at max 4*14MB of RAM), whereas
DSP memory size is much smaller...


	- Eero

PS. Remember that profiler information isn't per instruction, but per
address.  If instruction at given address changes, the disassembly
produced after profiling can be misleading.