Is Snow Leopard the last to support 32-bit Intel Macs?

[Amdahl]

That's not a valid comparison. x86 is to AMD64 as G4 is to G5.

Who told you that? Steve Jobs?

Every one of the chips you named above support a different architecture.

$ file /Applications/Chess.app/Contents/MacOS/Chess
/Applications/Chess.app/Contents/MacOS/Chess: Mach-O universal binary with 4 architectures
/Applications/Chess.app/Contents/MacOS/Chess (for architecture ppc): Mach-O executable ppc
/Applications/Chess.app/Contents/MacOS/Chess (for architecture ppc64): Mach-O 64-bit executable ppc64
/Applications/Chess.app/Contents/MacOS/Chess (for architecture i386): Mach-O executable i386
/Applications/Chess.app/Contents/MacOS/Chess (for architecture x86_64): Mach-O 64-bit executable x86_64

 

[northernmunky]

How many 64-bit OS X applications are out there under Leopard right now? Transmission is the only one I have.

• Limewire 5 (if Java is set to 64bit as default)
• Azureus (ditto)
• MySQL 5.1 (x86_64)
• Handbrake (unreleased build) http://handbrake.fr/?article=snapshot
• Adobe Lightroom 2
• Transmission 1.74+

 

[Eidorian]

• Limewire 5 (if Java is set to 64bit as default)
• Azureus (ditto)
• MySQL 5.1 (x86_64)
• Handbrake (unreleased build) http://handbrake.fr/?article=snapshot
• Adobe Lightroom 2
• Transmission 1.74+

Thanks for the new snapshot of Handbrake. Time to get it for Windows.

 

[Tibrim]

Who told you that? Steve Jobs?

Every one of the chips you named above support a different architecture.

$ file /Applications/Chess.app/Contents/MacOS/Chess
/Applications/Chess.app/Contents/MacOS/Chess: Mach-O universal binary with 4 architectures
/Applications/Chess.app/Contents/MacOS/Chess (for architecture ppc): Mach-O executable ppc
/Applications/Chess.app/Contents/MacOS/Chess (for architecture ppc64): Mach-O 64-bit executable ppc64
/Applications/Chess.app/Contents/MacOS/Chess (for architecture i386): Mach-O executable i386
/Applications/Chess.app/Contents/MacOS/Chess (for architecture x86_64): Mach-O 64-bit executable x86_64

Well, I'd do a bit of reading about x86-64 before making such comments. Please see this article: http://en.wikipedia.org/wiki/X86-64

First sentence should start you on the right path about x86 and x86-64's relationship to eachother:

"x86-64 is a superset of the x86 instruction set architecture which allows x86-64 processors to run existing 16- and 32-bit x86 programs without sacrificing speed or compatibility, and to run new programs written in an extended instruction set which supports a 64-bit address space and other capabilities."

 

[Amdahl]

Well, I'd do a bit of reading about x86-64 before making such comments. Please see this article: http://en.wikipedia.org/wiki/X86-64

First sentence should start you on the right path about x86 and x86-64's relationship to eachother:

"x86-64 is a superset of the x86 instruction set architecture which allows x86-64 processors to run existing 16- and 32-bit x86 programs without sacrificing speed or compatibility, and to run new programs written in an extended instruction set which supports a 64-bit address space and other capabilities."

SSE is a superset of x86. AMD64 is a different binary architecture. That is why there is a different binary stream for it in the Chess.app. That is why a program has to choose to run in AMD64 mode or x86 mode, not both simultaneously. That is why 64-bit QuickTime has to do IPC to load 32-bit codecs. That is why 64-bit Safari has to use IPC to load 32-bit Flash. The only truth to Wikipedia is the marketspeak: AMD64 chips boot up in x86 mode, and with OS support, can have processes executing in AMD64 or x86 mode. The kernel can run in x86 mode, while an app runs in AMD64 mode. (Hence Leopard) But one process can't do both, because AMD64 is NOT a superset of x86.

Is AMD64 binary compatible with x86? Very close, but no. The INC and DEC instructions are taken away, replaced with the REX prefix that controls access to 64-bit and the new registers. New binary machine code is used for INC and DEC instructions. This precludes (along with the whole 64-bit address thing) AMD64 from being a superset of x86. AMD kept AMD64 as close to x86 as possible, so that minimal reworking of existing compilers, assemblers, and assembly code would be needed to transition to AMD64. They were quite successful, obviously, with FreeBSD available on AMD64 in June 2003, and Windows XP in 2005. (Microsoft had to wait for Intel to ship their 64-bit processors, or else they would have seriously embarrassed their good buddy.)

If AMD64 was constrained by x86 (to be a true superset), it wouldn't have been able to do all the things that make it such an improvement. You think Intel wouldn't have already done those things 20 years ago, during the RISC vs. CISC battle, if it was that easy? No, the best they could do was SSE, which added some registers, but also imposed rules on how SSE instructions would execute and intermix with the non-SSE instructions. In addition, the OS had to be modified to make sure the new registers would be protected during context switches (aka multitasking). Windows 98 was the first version that allowed SSE to work. SSE pushed things the farthest you can go before you have a new architecture.

If you want technical data, try developer.amd.com.

 

[Eric S.]

Apple will have to support 32-bit applications for a long long time, just as you can run PowerPC applications on an Intel Mac under Snow Leopard, and that will have to continue to work for a long time.

As long as 32-bit applications are supported, there is very little reason to not support 32-bit Macs.

Didn't you undermine your own argument? If PPC applications are supported under 10.6 but PPC systems are not, can't we see foresee support for 32-bit applications under 10.7 but not 32-bit systems?

 

[Zeus86]

I hope they will still support 32-bit for a while. I just got my first gen Blackbook back from the Apple Store to have the hinges and top case and keyboard replaced, so this laptop is good as new. I pre-ordered Snow Leopard to so I can keep it running as new as possible. This laptop has been going strong for 3 years and I plan on using it for another 3 years.

 

[Amdahl]

I hope they will still support 32-bit for a while. I just got my first gen Blackbook back from the Apple Store to have the hinges and top case and keyboard replaced, so this laptop is good as new. I pre-ordered Snow Leopard to so I can keep it running as new as possible. This laptop has been going strong for 3 years and I plan on using it for another 3 years.

But don't you want to buy a new Apple iProduct? I hear Gizmodo has pictures of them taking it out of the box!!@! No? Ok, have a T-shirt!

I have a C2D Blackbook, but I don't think it is even able to boot 64-bit on SL.

 

[cube]

Who told you that? Steve Jobs?

Every one of the chips you named above support a different architecture.

$ file /Applications/Chess.app/Contents/MacOS/Chess
/Applications/Chess.app/Contents/MacOS/Chess: Mach-O universal binary with 4 architectures
/Applications/Chess.app/Contents/MacOS/Chess (for architecture ppc): Mach-O executable ppc
/Applications/Chess.app/Contents/MacOS/Chess (for architecture ppc64): Mach-O 64-bit executable ppc64
/Applications/Chess.app/Contents/MacOS/Chess (for architecture i386): Mach-O executable i386
/Applications/Chess.app/Contents/MacOS/Chess (for architecture x86_64): Mach-O 64-bit executable x86_64

It's not about whether they are different architectures or not, it's about the degree of similarity.

That's why the proper comparison of the x86/AMD64 pair is to G4/G5, not to x86/PPC.

 

[Amdahl]

It's not about whether they are different architectures or not, it's about the degree of similarity.

That's why the proper comparison of the x86/AMD64 pair is to G4/G5, not to x86/PPC.

Tthey(x86/AMD64) are different architectures. As for G4 vs. G5, Apple never shipped a 'G5(64-bit)' architecture kernel&kexts, so you're fighting an uphill battle with this argument already, because that would have been the 'most similar' set of architectures you can have, since PPC64 is very similar to PPC.

If you'd care to give me your technical opinion that compares and contrasts the 'degree of similarity,' I'd love to hear it. Really.

 

[err404]

I'm in the same boat with my C2D MBP. It has a 64bit CPU, but a 32bit chipset (pre-SR).
Keep in mind that Apple was selling new machines with 32bit chipsets only 6 months ago in the form of the Mac Mini. While I could see a policy to remove 32bit binary's from apps (killing compatibility with the original CoreDuo CPU) I would be surprised if the optional 32 kernel was cut out as early as 10.7.

I feel that this would be the best solution since 64 bit machines could run at full capability, the binary's wont have 32bit bloat and they minimize the number of obsolete machines to only the original CoreDuos (and the hit to Apple's marketshare).

 

[Amdahl]

I'm in the same boat with my C2D MBP. It has a 64bit CPU, but a 32bit chipset (pre-SR).
... While I could see a policy to remove 32bit binary's from apps (killing compatibility with the original CoreDuo CPU) I would be surprised if the optional 32 kernel was cut out as early as 10.7.

That is an interesting scenario. Certainly not impossible, but unlikely. I do suspect the 32-bit kernel gets the axe though; Hardware makers aren't going to like making two versions of all the drivers. Three versions, if they are still supporting PPC.

...they minimize the number of obsolete machines to only the original CoreDuos (and the hit to Apple's marketshare).

Apple learned you don't need marketshare if you can just keep selling to the same userbase over & over. Kind of like the Xbox 360.

 

[cube]

Tthey(x86/AMD64) are different architectures. As for G4 vs. G5, Apple never shipped a 'G5(64-bit)' architecture kernel&kexts, so you're fighting an uphill battle with this argument already, because that would have been the 'most similar' set of architectures you can have, since PPC64 is very similar to PPC.

If you'd care to give me your technical opinion that compares and contrasts the 'degree of similarity,' I'd love to hear it. Really.

I am not talinking about what kernels Apple made or not. I am saying that the work on maintaining x86/AMD64 ports should be compared to another related 32bit/64bit pair, not to x86/PPC.

 

[devburke]

Chess.app is. Someone mentioned Xcode a while ago but I don't think it is.

Chess.app! I literally loled.

 

[Tibrim]

SSE is a superset of x86. AMD64 is a different binary architecture. That is why there is a different binary stream for it in the Chess.app. That is why a program has to choose to run in AMD64 mode or x86 mode, not both simultaneously. That is why 64-bit QuickTime has to do IPC to load 32-bit codecs. That is why 64-bit Safari has to use IPC to load 32-bit Flash. The only truth to Wikipedia is the marketspeak: AMD64 chips boot up in x86 mode, and with OS support, can have processes executing in AMD64 or x86 mode. The kernel can run in x86 mode, while an app runs in AMD64 mode. (Hence Leopard) But one process can't do both, because AMD64 is NOT a superset of x86.

Is AMD64 binary compatible with x86? Very close, but no. The INC and DEC instructions are taken away, replaced with the REX prefix that controls access to 64-bit and the new registers. New binary machine code is used for INC and DEC instructions. This precludes (along with the whole 64-bit address thing) AMD64 from being a superset of x86. AMD kept AMD64 as close to x86 as possible, so that minimal reworking of existing compilers, assemblers, and assembly code would be needed to transition to AMD64. They were quite successful, obviously, with FreeBSD available on AMD64 in June 2003, and Windows XP in 2005. (Microsoft had to wait for Intel to ship their 64-bit processors, or else they would have seriously embarrassed their good buddy.)

If AMD64 was constrained by x86 (to be a true superset), it wouldn't have been able to do all the things that make it such an improvement. You think Intel wouldn't have already done those things 20 years ago, during the RISC vs. CISC battle, if it was that easy? No, the best they could do was SSE, which added some registers, but also imposed rules on how SSE instructions would execute and intermix with the non-SSE instructions. In addition, the OS had to be modified to make sure the new registers would be protected during context switches (aka multitasking). Windows 98 was the first version that allowed SSE to work. SSE pushed things the farthest you can go before you have a new architecture.

If you want technical data, try developer.amd.com.

Excellent points, and thanks for the explaination.

Now, I'd have to say, I agree with you on 10.7 going 64-bit with the kernel and core applications exclusively, but keeping the ability to execute 32-bit applications. This gives Apple and Manufacturers time to flesh out all the device drivers needed to support all intel macs that have 64-bit capable processors (its been stated many times that Macs with 64-bit capable processors, but have 32-bit EFI firmware are still capable of booting a 64-bit kernel).

The only major loss is the YONAH generation of Intel Macs, but this is Apple we're talking about... can't really be that surprised by this deprecation.

 

[Amdahl]

I am not talinking about what kernels Apple made or not. I am saying that the work on maintaining x86/AMD64 ports should be compared to another related 32bit/64bit pair, not to x86/PPC.

Then don't compare it to PPC. PPC was designed to go 64-bit(under the POWER tradename) from the beginning, and the ISA has only minimal differences. x86 was designed in 1970s, and Intel was so determined to avoid x86 going to 64-bit, that AMD created their own platform that Intel was forced to license back after Itanium flopped.

They are completely incomparable. In fact, I don't think you can find another example like x86->AMD64. 68K->PPC might qualify, but they are completely different architectures much like PPC->x86. PPC was designed to facilitate itself as the successor to 68K, as long as it didn't compromise the PPC agenda. SPARC went from 32-bit to 64-bit, but I think it was also just as smooth a transition as PPC because SPARC was a 32-bit RISC architecture designed in 1986, with the 64-bit designed in 1993. MIPS shipped in 1985, with 64-bit in 1991.

 

[jholzner]

Apple learned you don't need marketshare if you can just keep selling to the same userbase over & over. Kind of like the Xbox 360.

As I watch their unit shipments of Macs increase quarter after quarter I don't think they are just selling to the same user base over and over. Their user base is clearly growing.

 

[cube]

Then don't compare it to PPC. PPC was designed to go 64-bit(under the POWER tradename) from the beginning, and the ISA has only minimal differences. x86 was designed in 1970s, and Intel was so determined to avoid x86 going to 64-bit, that AMD created their own platform that Intel was forced to license back after Itanium flopped.

They are completely incomparable. In fact, I don't think you can find another example like x86->AMD64. 68K->PPC might qualify, but they are completely different architectures much like PPC->x86. PPC was designed to facilitate itself as the successor to 68K, as long as it didn't compromise the PPC agenda. SPARC went from 32-bit to 64-bit, but I think it was also just as smooth a transition as PPC because SPARC was a 32-bit RISC architecture designed in 1986, with the 64-bit designed in 1993. MIPS shipped in 1985, with 64-bit in 1991.

I know it's not a smooth transition and that it's not the same as with those RISC architectures. But the point was than x86 and PPC are COMPLETELY different.

 

[Riemann Zeta]

Probably yes. Windows 7 is the last version to support x32 chips as well--whatever Windows 8 happens to be called, it will only be released in the x64 flavor. Also, I believe that systems with so-called "32bit" chipsets can be rather easily tricked into running the real (x64) Snow Leopard kernel, even if Apple doesn't directly support it. Apple chose (unfortunately, in my opinion) to enable the x32 kernel by default in order to ensure compatibility with pre-10.6 kexts, drivers and low(er)-level 3rd party stuff.

 

[Infrared]

This is the Apple way: Abandon the slightly old product, to keep moving the platform forward and not become Windows.

Have Apple moved it far enough forward to catch up yet?

Windows had a 64-bit kernel in 2001. That's eight years ago.

 

[Infrared]

[Duplicate deleted]

 

[Infrared]

Probably yes. Windows 7 is the last version to support x32 chips as well--whatever Windows 8 happens to be called, it will only be released in the x64 flavor. Also, I believe that systems with so-called "32bit" chipsets can be rather easily tricked into running the real (x64) Snow Leopard kernel, even if Apple doesn't directly support it.

I think you mean 32-bit EFI x64 chipsets. And it's "x86", not "x32".

 

[Amdahl]

Have Apple moved it far enough forward to catch up yet?

Windows had a 64-bit kernel in 2001. That's eight years ago.

I've pointed out Apple has been selling the cult members 64-bit since they put the G5 on sale in 2003, and STILL haven't delivered it with Snow Leopard. (32-bit default kernel, many 64-bit Macs not able to boot 64-bit)

Really, what the heck is up with the Macs that can't boot 64-bit? I have never seen Windows, FreeBSD, or Linux be unable to boot a 64-bit processor in AMD64 mode due to 'chipset' issues.