Profiling code under WinUAE?

[deimos]

Is there any clever way to profile the 68K code I'm running under WinUAE?

I've written several different implementations of the stuff I'm working on, and the version that I think should be fastest isn't, and it would be great to get some insight into where each version is spending its time, but with a bit more precision and sophistication than I can get by inserting measurement code myself.

[roondar]

Well, there is at least one profiler for Amiga OS: http://aminet.net/package/dev/misc/AProf334

However, as I understand it's meant for C compiled code so I don't know what would happen with assembly programs or C programs with assembly added. Still, it's better than nothing I suppose. As for directly in WinUAE, I don't think there are tools like that. AFAIK most people custom code this stuff, either by using raster timing bars or using the CIA timers.

[dodke]

Are you coding for plain a500? The cycle exact mode should be quite accurate with that. Even with how active bitplanes / blitter etc affect CPU speed. For measuring speed setting different values in color0 register for different parts of code is common and I generally use that. For small routines you could repeat it.

[deimos]

Originally Posted by roondar

Well, there is at least one profiler for Amiga OS: http://aminet.net/package/dev/misc/AProf334

However, as I understand it's meant for C compiled code so I don't know what would happen with assembly programs or C programs with assembly added. Still, it's better than nothing I suppose. As for directly in WinUAE, I don't think there are tools like that. AFAIK most people custom code this stuff, either by using raster timing bars or using the CIA timers.

Thanks, I've googled that and found it on SourceForge. "can be used with all Amiga development languages that support the standard AmigaDOS symbol hunk format", so it sounds like I could probably use it, but it's not going to get me the level of information I need.

If I could have anything I wanted, I'd like to record what the virtual 68000 is doing at every instruction fetched while it's in my task, then match that up against the 1000 or so lines of code that I'm interested in to get an overview of how my code performs.

Wishes are free, I suppose.

[deimos]

Originally Posted by dodke

Are you coding for plain a500? The cycle exact mode should be quite accurate with that. Even with how active bitplanes / blitter etc affect CPU speed. For measuring speed setting different values in color0 register for different parts of code is common and I generally use that. For small routines you could repeat it.

I'd really like to get more detail than that would allow, and I'd really like it to be more automatic, so I can compare at both a high and low level how my two implementations behave.

[roondar]

Originally Posted by deimos

Thanks, I've googled that and found it on SourceForge. "can be used with all Amiga development languages that support the standard AmigaDOS symbol hunk format", so it sounds like I could probably use it, but it's not going to get me the level of information I need.

If I could have anything I wanted, I'd like to record what the virtual 68000 is doing at every instruction fetched while it's in my task, then match that up against the 1000 or so lines of code that I'm interested in to get an overview of how my code performs.

Wishes are free, I suppose.

The only other thing I can think of is looking into non-Amiga specific tools. The 68000 was used in a ton of embedded systems and other applications (still is to some limited degree) and a lot of professional software was made for it.

I'm fairly certain that full profilers and simulators (maybe even with the kind of features you'd like to have) exist in that world.

However, those options might not be affordable (let alone free ). And they also won't let you look at Amiga hardware specifics. So if you want to go that route, you might be able to get the profiler abilities you want, but forget about accessing Amiga hardware.

Oh well, one can indeed dream

[deimos]

Originally Posted by roondar

The only other thing I can think of is looking into non-Amiga specific tools. The 68000 was used in a ton of embedded systems and other applications (still is to some limited degree) and a lot of professional software was made for it.

I'm fairly certain that full profilers and simulators (maybe even with the kind of features you'd like to have) exist in that world.

However, those options might not be affordable (let alone free ). And they also won't let you look at Amiga hardware specifics. So if you want to go that route, you might be able to get the profiler abilities you want, but forget about accessing Amiga hardware.

Oh well, one can indeed dream

That's an interesting idea. The code I'm working on isn't very Amiga-specific, if I took out the code to set up the display and just reserved some pretend bitmap memory then maybe I could use a tool from the embedded world. Except those guys like to charge. A lot.

[Toni Wilen]

Profiling would be good fit with new debugger features (http://eab.abime.net/showthread.php?t=91321) but because most of these features are something I don't personally need and/or used: I need multiple good suggestions (which good enough explanation why doing it that way is good idea) before I'll implement it.

Also, at least when doing 68000 code, chipset (and what it is doing) is very important part than CPU which makes profiling for non-expanded configs very non-trivial and make results random-looking..

[deimos]

I'd love to see a separate tool next to uaedbg that runs an Amiga executable in a similar way, but on exit outputs a CSV that could be interpreted by tools on the Window's side, or just viewed by braver souls. If it could have enough information to reconstruct the drill-down style interface that you get with, say, Java profilers, that would be awesome, but even starting with the number of cycles spent in each instruction in a way that could be compared to the original source would be enough to be useful.

Originally Posted by Toni Wilen

Profiling would be good fit with new debugger features (http://eab.abime.net/showthread.php?t=91321) but because most of these features are something I don't personally need and/or used: I need multiple good suggestions (which good enough explanation why doing it that way is good idea) before I'll implement it.

Also, at least when doing 68000 code, chipset (and what it is doing) is very important part than CPU which makes profiling for non-expanded configs very non-trivial and make results random-looking..