Search results

Okay, I did it! I've written a sampling profiler, and I'm actually getting usable data from it. Now I can see exactly what lines of code in my game are sucking up all the time. This'll make it a ton easier to optimize. It took a bit to get it right too. My samples include not just the stored...

Yeah, I have no ambition to make a global profiler. Just one for the current application, included as a library similar to PerformLib. I might be able to sidestep the issue of different code segments, because when compiling with Retro68, it does everything as one big segment, unless you...

I think I'm getting close to finishing my Retro68 compatible sampling profiler. I have another question I'm hoping somewhere here knows the answer to. When I have an address from the Program Counter, how do I figure out what the relative address is to the segment of code its executing in...

I missed that! But yes, that explains it, and surely will make this more reliable. Thanks for pointing that out!

Ah yes, I forgot about that ResEdit extension! I actually already have it installed in one of my systems, but forget to use it. In any case, I think I've got the search for the stack offset working, using Apple's rather strange method. There very well may be a better way of doing it buried in...

@David Cook Sorry I'm not sure if this is pinging you correctly! Okay I got it. Apologies to the user whose username is simply "David" for pinging you accidentally.

@david_cook What disassembler are you using? I'm starting to suspect that Ghidra is unreliable, in that it's not getting some of the jump instructions correctly, even when I used the linked library.

Yes, I have been using the raw library, and I didn't realize some of those statements would be changed after linking. Thanks for pointing that out! I would've ended up chasing my tail for quite a while otherwise. I built the example app using MPW, so I'll try disassembling that. I believe...

Well, if it's good enough for Apple.... But there's still more to the story. If I just scan through what's on the stack naively, I never find what I'm looking for. Their code however is doing something with the A5 register. Here's what I'm seeing, using a different disassembler that handles...

I'm getting a little further with this. I'm looking at the routine (revealingly) named CalcPCOffset. It looks like what it does is set up a Time Manager task to fire, then loops endlessly with a 60 FE BRA.S $0000 statement. Because there's now only one instruction execution could be at during...

Doing more analysis... I think the key is in these lines: 0001133a 30 3a 00 68 move.w (0x68,PC)=>DAT_000113a4,D0w 0001133e 20 37 00 00 move.l (0x0,SP,D0w*0x1),D0 Somehow DAT_000113a4 is assigned to the right offset value for the stack to get at the stored PC at interrupt time...

Here's the entire interrupt function, as disassembled by Ghidra: TimerInterruptFunc XREF[3]: L318.__z37___z37_PERFORM:0001124...

I've been pouring over a disassembly of it using Ghidra, trying to work out how its interrupt function determines where the Program Counter was at interrupt time. So far I haven't gotten anything! Though I do believe I figured out where the interrupt function is. It doesn't look like CodeWarrior...

For now I'll be happy if it can work on just one system. But it would be nice to have a general solution, which is why I was hoping I could get PerformLib to compile.

Okay... progress! It occurred to me I might be able to avoid the linking issue if I could use MPW to create a library that already has all of the symbols linked. And so I did... combining together PerformLib and Interface. I also had to resolve symbols to memcpy and memchr, but once I did...

I just noticed this bit of text in Retro68's README about ConvertObj: That strongly suggests that trying to get Retro68 linking PerformLib.o is a dead end. :-(

Okay, I think I see the issue, though I'm not sure if there's much I can do about it. If I run Retro68's ConvertObj tool to convert MPW's PerformLib.o into a gcc assembly file, I can see that the various symbols in it are listed like: .short GETFPOS-. That only gives it 2 bytes, meaning it can't...

Interesting idea. I gave it a try, but I don't think it's revealing, because the problem seems to stem not from linking my code to the functions in libPerformLib, but rather linking libPerformLib to libInterface. I wonder if this is an issue when converting MPW static libraries to gcc?

Alas, using segments didn't help with linking to PerformLib. In case it's a clue, I can link to it so long as I don't call either InitPerf or PerfDump. Linking those two functions is what triggers the error.

I don't believe I'm building with -mpcrel, and don't see it in the build output. (And I tried building with -fPIC as an experiment, but it caused a legit gcc error, so I'm assuming that retro68 doesn't supports it.)