[hatari-devel] Profiling support to Hatari debugger

npomarede at corp.free.fr npomarede at corp.free.fr
Mon May 3 23:08:22 CEST 2010


On Mon, 3 May 2010, Eero Tamminen wrote:

>> to get more users output and see how this could be integrated to fit
>> best with external programs that could process these data
>
> I think the main issue is in getting symbols information to Hatari.
> Currently only AHCC provides it in suitable format (after Henk has changed
> the addresses from decimal to hex, similarly to "nm", in next AHCC release).
>
> What kind of post-processing you were thinking for the information
> coming out of Hatari?

Hello,

I was thinking about something that would take all the addr/count 
statistics and build some graphs or things like that. Certainly some input 
format should be followed to get interesting results.

>
>> (and with what users would like to do with these).
>
> GCC users have also gprof (I assume it works also on Atari), so this profile
> stuff is more interesting for people using less advanced C-compilers or
> writing direct assembly.  After profile has cycle information, demo writers
> should be more interested in it. :-)

This could be useful to profile some complex routines, but I'm not that 
sure for demos ; demos coders already use motorola cycles tables and as 
many demos are using overscan, profiling is not the real problem, it's 
more about combining instructions in the right order to optimise the range 
of available cycles between some fixed positions.

> While on cycle accuracy, how do I get the information about how many cycles
> the previous instruction used?  For CPU?  For DSP?

In m68k_run_1(), "cycles" contains the result for the last opcode. In case 
some special processing should be made, there's already the code block :

         if (regs.spcflags) {
             if (do_specialties ())
                 return;
         }

In that case, we could modify do_specialties() to take "int cycles" as an 
argument, and put some redirection to profiling code in do_specialties().

But in the end, this could impact performance when profiling is on. I 
think a better approach could be :

  - use #if/#endif to turn profiling code on/off if the user really wants 
it. Efficent, but less user friendly as you need to recompile.

  - create m68k_run_3() for example with all the additional "slower" 
profiling code and add some code in main() to call the correct m68k_run_X 
function.

>
>
> Also, I'm currently assuming (to save memory) that CPU and DSP instructions
> can never be on odd addresses.  Is that correct?

It's true for CPU (else you will get an exception). I don't know for DSP.


Nicolas



More information about the hatari-devel mailing list