Previous Thread
Next Thread
Print Thread
Page 8 of 10 1 2 6 7 8 9 10
Joined: Jul 2006
Posts: 87
L
Member
Member
L Offline
Joined: Jul 2006
Posts: 87
Oh it's a Mac specific thing?

Anyway the profile looks like this on my PC:
Code
 35.55     11.46    11.46   249608     0.00     0.00  cpuexec_timeslice
  9.40     14.49     3.03 198763356     0.00     0.00  cpu_execute_m68k
  6.61     16.62     2.13     8762     0.00     0.00  segaic16_sprites_outrun_draw
  4.75     18.15     1.53   145988     0.00     0.00  drawsdl_rgb888_setup_and_draw_textured_quad
  4.47     19.59     1.44  7421604     0.00     0.00  ym2151_update_one
  3.88     20.84     1.25 35382713     0.00     0.00  cpu_execute_z80

Joined: Mar 2001
Posts: 17,239
Likes: 263
R
Very Senior Member
Very Senior Member
R Offline
Joined: Mar 2001
Posts: 17,239
Likes: 263
Yeah. The fact that a signal handler's involved makes it look *very* Mac specific.

Joined: Sep 2002
Posts: 25
S
Member
Member
S Offline
Joined: Sep 2002
Posts: 25
Originally Posted by Just Desserts
Well, hook up Instruments to the previous version, and see if the profile layout is the same. Then, if it's not, I think Kent might be happy if you tried to figure out why the app is spending so much time in those functions. Most of us on the Bannister boards aren't running Macs, so you're one of the few people who actually stands a chance at fixing it. smile

So, the sigaltstack and sigprocmask calls were shown up by the 'Time Profiler' in Instruments. That just showed them as coming straight from cpuexec_timeslice.

If I run 'CPU sampler', then it actually shows a 'setjmp' in between the sigaltstack/sigprocmask and cpuexec_timeslice.

Going into m68kcpu.c / m68kcpu.h, then there is a call to setjmp in the macro m68ki_set_address_error_trap().

If I comment out the use of that macro in CPU_EXECUTE(), then Out Run runs at full speed smile

Now, I'm not going to suggest removing that macro / setjmp() call, without knowing a lot more about why it's there in the first place!! But that is why some m68k games are running really slow on a Mac.

Joined: Mar 2001
Posts: 17,239
Likes: 263
R
Very Senior Member
Very Senior Member
R Offline
Joined: Mar 2001
Posts: 17,239
Likes: 263
Scarlet, that's awesome. There was just a controversy about that very setjmp() on the dev list (apparently 64-bit MSVC doesn't like it either), I'll make sure to bring it up again.

Joined: Sep 2002
Posts: 25
S
Member
Member
S Offline
Joined: Sep 2002
Posts: 25
Yes, just seen there is a post about it on the Mess board as well (64-bit MSVC that is).

Searching for setjmp performance, it appears to be undefined by POSIX exactly what it will do - it may or may not save the signal context (ie. SYSV doesn't, BSD 4.3 does).

Which explains why it acts like a dog on Mac (and other BSDs) - it's saving the signal context.

There is _setjmp() that doesn't save the context, although it's probably equivalent and better to use sigsetjmp(buf, 0) - I'm just about to test (once the compile finishes!!).

Don't know if that will do anything for 64-bit MSVC, but you might want to give it a shot.

UPDATE: Yes, sigsetjmp(buf, 0) works fine on the Mac. No saving of signal contexts smile. Obviously, need to update jmp_buf to sigjmp_buf and longjmp() to siglongjmp() to match.

Last edited by scarlet; 09/15/09 08:37 PM.
Joined: Mar 2001
Posts: 17,239
Likes: 263
R
Very Senior Member
Very Senior Member
R Offline
Joined: Mar 2001
Posts: 17,239
Likes: 263
Need to figure out what it's actually *doing* first - I've never used setjmp() in a CPU core before so it seems very odd that the 68k is doing so.

Joined: Sep 2002
Posts: 25
S
Member
Member
S Offline
Joined: Sep 2002
Posts: 25
Well, according to the naming, it's being used as a return point when checking for an 'address error'.

And a quick grep says that setjmp() is also being used in:

mips3drc
ppc602
ppc603
ppcdrc
sh2drc

and once in mame.c for a fatal error.

Interestingly, ppc602 has comments to say that MinGW's optimizer kills setjmp()/longjmp().

As you say, best line of code is the one that doesn't exist smile

Joined: Mar 2001
Posts: 17,239
Likes: 263
R
Very Senior Member
Very Senior Member
R Offline
Joined: Mar 2001
Posts: 17,239
Likes: 263
Thanks. I submitted a patch for u1 that keys off _BSD_SETJMP_H to select sigsetjmp() and friends, co-credited to you. Works well on my Mac Mini and doesn't break Linux or Windows.

Joined: Sep 2002
Posts: 25
S
Member
Member
S Offline
Joined: Sep 2002
Posts: 25
Cheers, always fancied having a credit in the Mame source, but no time to do anything! It's been good looking at C code, which I haven't done in a long time.

Would be interesting to know if the address error emulation is really necessary though. Although the sigsetjmp() version works at a reasonable pace, the version I compiled that simply commented out the setjmp() call is a good 10-25% faster than sigsetjmp() running Out Run.

Maybe next I'll see if I can work around the compilation errors using clang!

Joined: Mar 2001
Posts: 17,239
Likes: 263
R
Very Senior Member
Very Senior Member
R Offline
Joined: Mar 2001
Posts: 17,239
Likes: 263
The emulation of it's definitely necessary - a couple of games actually deliberately jump to an invalid address in order to continue via the address error vector. If the whole mechanism could be coded better is an open question smile

Page 8 of 10 1 2 6 7 8 9 10

Moderated by  R. Belmont 

Link Copied to Clipboard
Who's Online Now
1 members (1 invisible), 57 guests, and 2 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,331
Posts122,197
Members5,077
Most Online1,283
Dec 21st, 2022
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Powered by UBB.threads™ PHP Forum Software 8.0.0