68k Any sampling profilers for Mac 68k?

I'm been exploring profiling the code I'm writing, and I'm wondering what options are available. I've gotten CodeWarrior Pro 4's profile working, and while it certainly provides some useful information, it only provides timing on a per-function basis. I'm wondering if anyone made a sampling profile that can get down to the granularity of individual lines of code, like most modern profilers?

Also, this is mainly for my game project that I've got compiling with both Retro68 and CodeWarrior, so I'm curious about whether it's possible to profile the Retro68 build. Unfortunately using gcc's profiling features / gprof doesn't seem to work, since I don't think they support 68k.

I suppose if I wanted to get crazy, I could roll my own. In theory I could create a timer that fires every X microseconds, take note of what code was being executed before the interrupt, and then somehow figure out which lines of code it was using debugging data generated by gcc. But that's a wheel I'd rather not reinvent!

I said I didn't want to reinvent that wheel... but I gave it a shot! I had the sense of what was the difficult part reversed, though. Correlating an instruction address with a line of code is fairly easy -- that's what building with debugging information is for.

But I haven't figured out how to catch what was last being executed at interrupt time. I thought it'd be straight forward, because according to Inside Macintosh, when an interrupt occurs, the Program Counter gets pushed on to the stack. And so I used Time Manager to write a function that would fire regularly and inspect the stack to see what was being called.

The trouble is, at least for Time Manager and VBL interrupts, the OS is doing a bunch of stuff behind the scenes to make it possible for a normal C or Pascal function to be called at interrupt time, and then restoring the previous state after that function finishes. So the stack is in a totally unpredictable state when my timer function is called, and there's no clear way to figure out where execution is eventually going to return to. Or at least, none that I've found so far.

Is it actually possible to figure out what the Program Counter was at interrupt time in a Time Manager task?

David Cook said:

Here's a possible approach.

1. Run a test program that shows an alert with it's address range when it starts up. Then have it do some heavy looping with occasional calls to WaitNextEvent/GetNextEvent.
2. Add a debug breakpoint in your Time Manager program.
3. Each time it breaks, dump the stack in Macsbug until you find an address in the range of your test program. I assume a pattern will emerge of where the return address is located.

Click to expand...

I did something that I think is basically equivalent to that:

Each time my Time Manager task fired, I had it get the address of the stack, and then scan through it looking for anything that could be an address of my program (looking for specific address ranges). I then had it print all of those -- possible because I'm running in an emulator and the printing happened on the host system -- and look for a pattern.

Unfortunately what I found is that the return address was not in a consistent position, and sometimes it wasn't there at all.

That said, your idea might be the better one, because naturally my Time Manager task is probably changing the stack by virtue of running compiled code -- the old "changing the result by measuring it" issue.

I'm still learning to use MacsBug though. How do I set a breakpoint when my task fires?

Awesome, thanks! Also, I figured out how to trigger MacsBug in my code. As simple as Debugger()

Checking with the debugger, I'm still seeing inconsistent layout of the stack at interrupt time. I'll take a look at the Time Manager source code and see if anything can be gleamed from that.

David Cook said:

Hold the phone! What is this?

sys71src/Interfaces/CIncludes/Perf.h at main · laniku/sys71src

Apple Macintosh System Software 7.1 source leak (m68k + basic PPC) - laniku/sys71src

github.com

Did Apple already create a performance library? You may just need to call this and then convert the report file into routine names via the debug data file.

Click to expand...

Whaaat! I'm definitely going to take a look at that!