Previous Thread
Next Thread
Print Thread
Page 9 of 10 1 2 7 8 9 10
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
Well, the compiler's part of Xcode so transplanting it would be tricky. You can build stuff on Leopard with Xcode 3 that runs on Tiger and even Panther though.

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
Vas: thank you again, that brought back the performance. (I have a simple test: if the Midway logo FMV hovers around 150% unthrottled in Blitz, the 3dfx speedups are cranking). Ridge Racer's also a few ticks faster as advertised. I'll test on all 4 systems and post it soon.

Joined: Sep 2006
Posts: 89
M
Member
Member
M Offline
Joined: Sep 2006
Posts: 89
Originally Posted by etabeta78
Originally Posted by R. Belmont
I think it's irritating that Xcode 3 doesn't run on Tiger.

do you think the new gcc compiler will appear also for the old Xcode? or will we need to upgrade to Leopard to be able to play virtua racing on mac?

It pains me to say it, but XCode 3.0 is still using gcc 4.0.1. frown

Code
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5465)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

So, no Virtua Racing love from a stock Leopard install.

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
Have you verified that? The build is newer (I have 5341 on PowerPC and 5367 on Intel) and Dave Dribin said they definitely fixed some reported bugs.

Joined: Sep 2004
Posts: 392
Likes: 4
A
Senior Member
Senior Member
A Offline
Joined: Sep 2004
Posts: 392
Likes: 4
Originally Posted by Vas Crabb
Well, I'm not sure it I've fixed the performance regression, but I did manage to do a lot of cleanups.
Thanks for your help here. I'm not very experienced at the GCC inline assembly syntax (obviously!)

Quote
First up, eminline.h only defined compare_exchange_ptr if PTR64 was defined. This is silly; we need it on 32-bit platforms, too.
That was not intentional. My bad.

Quote
After fixing that, I couldn't get GCC to shut up about cast warnings without using a local variable to store the result before returning.
I've had a lot of problems with GCC doing that as well.

Quote
Second, eigccppc.h was all over the place - the constraints were far less than optimal and there were invalid opcodes scattered through it.
Sorry about that. smile It was my attempt to copy/paste the existing PPC code from everywhere, merge it together, and make some logical (apparently not) guesses about how it should work. My PowerPC is very rusty, tho!

Quote
On top of that, the constraints were often less than optimal or even unsafe in some cases. So I straightened the constraints out and made the assembly clearer (named operands and all that).
Yeah, I didn't know you could name the constraints. All the old GCC inline assembly we had used %0 %1 and the like and it does get downright confusing to parse (especially on x86 with the goofy backwards operand order).

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
Well, actually Intel is backwards smile

Joined: Sep 2004
Posts: 392
Likes: 4
A
Senior Member
Senior Member
A Offline
Joined: Sep 2004
Posts: 392
Likes: 4
Originally Posted by R. Belmont
Well, actually Intel is backwards smile

Eh, it's a stupid argument. The manufacturer who defines the mnemonics gets to choose the operand order. Too bad if you don't like it. It's the same thing as the big-endian/little-endian debate, which I used to engage in all the time back when I was a crazy Mac zealot.

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
Well, actually, there's one right answer for both arguments, and it's based on how humans read things. The AT&T assembly syntax (as per GCC) is how humans read things, and big-endian is how humans read things. Ergo, both are correct. (And I'm saying this as a 6502 guy). Intel syntax is apparently intended for use by dyslexics.

Joined: Sep 2004
Posts: 392
Likes: 4
A
Senior Member
Senior Member
A Offline
Joined: Sep 2004
Posts: 392
Likes: 4
I have to totally disagree about AT&T syntax. If that were true, then it would be:

Code
opcode   dest,src1,src2      ; dest = src1 <op> src2
and not the goofy

Code
opcode   src1,src2,dest      ; WTF are they thinking?
IIRC, both PowerPC and MIPS work like the first case, so AT&T syntax is frankly goofy in any sense. Even with 2 operands, Intel makes far more sense to me, where I look at it as:

Code
opcode   dest,src            ; dest <op>= src

Joined: May 1999
Posts: 616
Likes: 1
Senior Member
Senior Member
Joined: May 1999
Posts: 616
Likes: 1
I found it completely backwards (yeah, bad pun intended) having destination first in the statement when I was exposed to that kind of syntax many years ago (if memory serves well, assembly on the Z80 used it) after studying machine code initially on a 6502.

That puts me strongly in R. Belmont's camp smile

Last edited by Carbon; 11/03/07 09:11 PM.
Page 9 of 10 1 2 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