Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

EFI32 Downsides?

N

neckarb

macrumors regular
Original poster
Jun 29, 2007
171
0
Hey Guys,
I've got a 2006 Mac Pro, very happy with it in every respect, my specs are below. There is no reason for me to upgrade that I can see buuuut it obviously has a 32bit EFI, other than the potential incompabitibility with future operating systems, which we can speculate about all day but come up with no real conclusions, what are the problems with having a 32bit EFI? OK so I also can't boot a 64Bit Kernal, but as I don't need to...?

- 2 x Quad Xeon X5355's @2.66 overclocked to @3.2ghz - 1.313v FSB@1600mhz
- 12GB DDR2 FB-DIMM Kingston RAM @800Mhz
- Sapphire 5870 1GB + XFX 5970 2GB Crossfirex 850/1200
- SATA III 6GB/s + USB 3.0 Asus U3S6
- Bluetooth 2.1 + Airport 802.11n
- 2 x 64GB OCZ Vertex 2E SSD's RAID 0 - Mac OS X 10.6.4
- 60GB Crucial C300 6GB/s - Windows 7 Pro x64
- 1.5TB WD Green - Mac
- 1.0TB WD Green - NTFS
- Liteon Blu-Ray R/W x12
- Apple 1000w PSU
- 5.25" 450 PSU
 
I dont think it will be an issue. Plenty of people boot in 32 bit on the 2008/2009 Mac Pros.

Maybe in the future programs will only run with a 64 bit kernal.... but we dont know when.
 
mjsmke said:
I dont think it will be an issue. Plenty of people boot in 32 bit on the 2008/2009 Mac Pros.

Maybe in the future programs will only run with a 64 bit kernal.... but we dont know when.
Click to expand...

This is what I'm thinking it's going to be a long time before people arn't running 32bit apps anymore.
 
neckarb said:
This is what I'm thinking it's going to be a long time before people arn't running 32bit apps anymore.
Click to expand...

Not applications. 32-bit applications run fine on 64-bit systems since 64-bit is essentially a super-set of 32-bit.

Instead it should be drivers/kexts you should be concerned about. 32-bit kexts can't be used with a 64-bit kernel and vice versa.

But, it still shouldn't really be a worry - most device manufacturers shouldn't be half-assed enough to develop 64-bit only drivers. Cause well, it's not hard to tick a flag and say compile for both.
 
Vylen said:
Not applications. 32-bit applications run fine on 64-bit systems since 64-bit is essentially a super-set of 32-bit.

Instead it should be drivers/kexts you should be concerned about. 32-bit kexts can't be used with a 64-bit kernel and vice versa.

But, it still shouldn't really be a worry - most device manufacturers shouldn't be half-assed enough to develop 64-bit only drivers. Cause well, it's not hard to tick a flag and say compile for both.
Click to expand...

What I meant is when 128bit processor architectures come into production... in a LONGGGG time, then the low end of operating system will be 64bit then 32bit applications wont run. Much in the same way that you can't run 16bit apps on a 64bit O.S

I didn't know about the drivers though, but yeah I can't imagine they will be developing only 64bit drivers anytime soon.
 
Honestly? Unless you're developing 64-bit kernel extensions, it won't make a blind bit of difference for a long time. I have a Mid-2010 iMac, and even though it has a 64-bit EFI, it boots the 32-bit kernel by default. There's no way device driver writers are going to skip 32-bit versions of their software for the foreseeable future.

Everything running on top of the kernel can run in 64-bit and address as much memory as they need, unlike Windows where booting the 32-bit system limits the entire OS to 3Gb of RAM.
 
Kenndac said:
Honestly? Unless you're developing 64-bit kernel extensions, it won't make a blind bit of difference for a long time. I have a Mid-2010 iMac, and even though it has a 64-bit EFI, it boots the 32-bit kernel by default. There's no way device driver writers are going to skip 32-bit versions of their software for the foreseeable future.

Everything running on top of the kernel can run in 64-bit and address as much memory as they need, unlike Windows where booting the 32-bit system limits the entire OS to 3Gb of RAM.
Click to expand...

Exactly what I was thinking, I can boot into 64bit mode no problem so I don't really see the big whoop.
 
Kenndac said:
Honestly? Unless you're developing 64-bit kernel extensions, it won't make a blind bit of difference for a long time. I have a Mid-2010 iMac, and even though it has a 64-bit EFI, it boots the 32-bit kernel by default. There's no way device driver writers are going to skip 32-bit versions of their software for the foreseeable future.

Everything running on top of the kernel can run in 64-bit and address as much memory as they need, unlike Windows where booting the 32-bit system limits the entire OS to 3Gb of RAM.
Click to expand...

FYI, the new Mac Pro boot 64 bit by default. Not that it matters much at this point.

To the OP - probably won't make much difference in the short term (2-3 years). Might be a big deal after that. I find it a little hard to believe Apple will make Lion 64bit EFI only - that would really EOL everything but very recent machines. A bit early for that in my opinion. They only recently EOL'd the PowerPC stuff with respect to OS X.
 
khollister said:
FYI, the new Mac Pro boot 64 bit by default. Not that it matters much at this point.

To the OP - probably won't make much difference in the short term (2-3 years). Might be a big deal after that. I find it a little hard to believe Apple will make Lion 64bit EFI only - that would really EOL everything but very recent machines. A bit early for that in my opinion. They only recently EOL'd the PowerPC stuff with respect to OS X.
Click to expand...

Yeah this is what I was thinking, for them to alienate so many Intel based Mac's for no real reason I'd be surprised.
 
neckarb said:
What I meant is when 128bit processor architectures come into production... in a LONGGGG time, then the low end of operating system will be 64bit then 32bit applications wont run. Much in the same way that you can't run 16bit apps on a 64bit O.S
Click to expand...

But... that's not how it works >_>

There's reason why common 64-bit systems are called x86-64. It's an extension to the 32-bit architecture. It's why I said 64-bit is a superset of 32-bit, and why 32-bit applications will always work (assuming they're x86 and x86-64).

Consequently, if AMD/Intel make a 128-bit instruction set by tacking it onto x86-64, then a 128-bit computer will run 32- and 64-bit applications fine. However, if the future 128-bit design is completely different, then both current 32-bit and 64-bit applications would require emulation.

Either way, all moot for the near future :p
 
Vylen said:
But... that's not how it works >_>

There's reason why common 64-bit systems are called x86-64. It's an extension to the 32-bit architecture. It's why I said 64-bit is a superset of 32-bit, and why 32-bit applications will always work (assuming they're x86 and x86-64).

Consequently, if AMD/Intel make a 128-bit instruction set by tacking it onto x86-64, then a 128-bit computer will run 32- and 64-bit applications fine. However, if the future 128-bit design is completely different, then both current 32-bit and 64-bit applications would require emulation.

Either way, all moot for the near future :p
Click to expand...

Didn't realise that, thanks :)
 
ActionableMango said:
I think you answered your own question. Who cares if it's 32bit EFI if you are very happy with it in every respect.
Click to expand...

Well, yeah it's good to be happy with what you've got, but I don't know all the upsides and downsides, it's best to be well informed.
 
neckarb said:
Well, yeah it's good to be happy with what you've got, but I don't know all the upsides and downsides, it's best to be well informed.
Click to expand...
Graphics card choices for those machines is already limited, and OS X will go to K64 only at some point (doesn't look like Lion though, so plan for that to happen with 10.8).

So if the machine will serve you well until that point (say next 2 - 3 years), then it will be fine.

BTW, these problems don't exist under Windows or Linux (works fine with 64 bit versions of these OS's, and even newer PC based graphics cards), so that's another way to get more service life out of it. Just a thought. ;)
 
nanofrog said:
Graphics card choices for those machines is already limited, and OS X will go to K64 only at some point (doesn't look like Lion though, so plan for that to happen with 10.8).
Click to expand...

I'm not sure why people keep saying this, when there is absolutely zero evidence to support this.

People continuously said that 10.7 would likely not support K32, and so far that hasn't panned out either.

A lot of machines besides that Mac Pro are 64 bit, and yet still only support K32. There is very little chance of this happening in the near future. I'd say there is at least another 2-3 years before there is any chance of this happening, at least.

There just is no logical reason why Apple would do this, especially with the large volume of machines out there that are K32 only.
 
goMac said:
There just is no logical reason why Apple would do this, especially with the large volume of machines out there that are K32 only.
Click to expand...
Apple stated that the K32 + K64 OS an interim product, so wouldn't be in service for long (it's been awhile ago, but it was on the front page of MR). I presume that it didn't happen with Lion due to the time it's taking to move from the Carbon to Cocoa API environment.

As per why to do this, it will get around the 64bit support problems in Cocoa, and reduce their workload (no more dual support). Which translates to fewer development and validation hours and that means money would be saved.

Their more recent history indicates that they're not interested in a long support cycle, and seem to be focused on around 3 years rather than 5 (or more that has been seen in the past). As a result, they can make more money this way (reduced support costs + additional systems sold as users will need to keep up with their industry = more profit per quarter/half/year).
 
goMac said:
There just is no logical reason why Apple would do this, especially with the large volume of machines out there that are K32 only.
Click to expand...

Support. One Mac OS X release required a Mac with FireWire (10.4, IIRC). Why? Just so they didn't have to support Macs that were old enough to not have FireWire. The OS itself would run just fine if you got it installed. I can totally see Apple dropping support for EFI32-only machines. I'm not worried about it.
 
yeah support, development costs, testing it all gets expensive with 2 versions to do. if lion isnt 64bit only then i could see the next one being so
 
nanofrog said:
Apple stated that the K32 + K64 OS an interim product, so wouldn't be in service for long (it's been awhile ago, but it was on the front page of MR). I presume that it didn't happen with Lion due to the time it's taking to move from the Carbon to Cocoa API environment.
Click to expand...

Where did they state this? Why would this have anything to do with the Carbon to Cocoa move?

nanofrog said:
As per why to do this, it will get around the 64bit support problems in Cocoa, and reduce their workload (no more dual support). Which translates to fewer development and validation hours and that means money would be saved.
Click to expand...

K32 doesn't have any problems with 64 bit Cocoa. The 64 bit ABI was actually specced out well before K64 even existed.

nanofrog said:
Their more recent history indicates that they're not interested in a long support cycle, and seem to be focused on around 3 years rather than 5 (or more that has been seen in the past). As a result, they can make more money this way (reduced support costs + additional systems sold as users will need to keep up with their industry = more profit per quarter/half/year).
Click to expand...

Is there any support cycle at all for K32?

NoNameBrand said:
Support. One Mac OS X release required a Mac with FireWire (10.4, IIRC). Why? Just so they didn't have to support Macs that were old enough to not have FireWire. The OS itself would run just fine if you got it installed. I can totally see Apple dropping support for EFI32-only machines. I'm not worried about it.
Click to expand...

karsten said:
yeah support, development costs, testing it all gets expensive with 2 versions to do. if lion isnt 64bit only then i could see the next one being so
Click to expand...

There really isn't that much support to be done... And they'd lose support for tons of models of Mac Pros. It simply doesn't make sense. I haven't seen any solid evidence to back this up, and I haven't heard anything through the grapevine. The only thing I've ever heard is that Apple has considered dropping 32 bit processor support, but not K32, as there are just way too many 64 bit machines that use K32.
 
goMac said:
Where did they state this? Why would this have anything to do with the Carbon to Cocoa move?
Click to expand...
As I said, it was an article on the front page some months ago.

As per Carbon, their own applications suites are having problems running in 64bit under Carbon as I understand it, and are transferring everything over to Cocoa (slower going than initially planned I think). To me, this is more of the issue than the OS itself needing to be K64 for its own sake (want a single API environment for simplification for both their and 3rd party application development).

goMac said:
K32 doesn't have any problems with 64 bit Cocoa. The 64 bit ABI was actually specced out well before K64 even existed.
Click to expand...
But there are still limitations under K32 (hint: 36bit addressing to get around hardware limitations).

goMac said:
Is there any support cycle at all for K32?
Click to expand...
I've not seen anything listed, but they'd have to have some sort of internal roadmap of what they're planning and when it's supposed to be implemented (subject to revision of course, and as it's not public, doesn't matter to the outside world as they see it).

Publishing it could even be detrimental in terms of short term system sales.
 
nanofrog said:
As I said, it was an article on the front page some months ago.
Click to expand...

Yeah, I'd like a link, but that sounds very suspect....

nanofrog said:
As per Carbon, their own applications suites are having problems running in 64bit under Carbon as I understand it, and are transferring everything over to Cocoa (slower going than initially planned I think). To me, this is more of the issue than the OS itself needing to be K64 for its own sake (want a single API environment for simplification for both their and 3rd party application development).
Click to expand...

Carbon doesn't run under 64 bit. At all. So this problem can't exist to begin with. This is very faulty info. It also directly conflicts with what I've heard.

The delay is because in since Cocoa is the only environment that supports 64 bit, they are porting them all to Cocoa. It has nothing to do with the kernel. The decision to cut 64 bit Carbon was made well before K64 even existed.

In fact, neither the Carbon or Cocoa ABI's are really tied to the architecture that the kernel is running under anyway. I don't at all see how this is tied to K32/K64.

nanofrog said:
But there are still limitations under K32 (hint: 36bit addressing to get around hardware limitations).
Click to expand...

Which isn't a reason to drop K32 builds.

nanofrog said:
I've not seen anything listed, but they'd have to have some sort of internal roadmap of what they're planning and when it's supposed to be implemented (subject to revision of course, and as it's not public, doesn't matter to the outside world as they see it).

Publishing it could even be detrimental in terms of short term system sales.
Click to expand...

I'm sure they do, but K32 is probably at the bottom of what they'd like to cut. The code differences between K32 and K64 are somewhat trivial. I highly doubt there is even a full time engineer just for K32.

Honestly, I'd say the only thing that I see that could cause them to drop K32 is if they dropped Mach entirely, but that's a whole nother can of worms...
 
goMac said:
Yeah, I'd like a link, but that sounds very suspect....
Click to expand...
I looked (wouldn't mind seeing it again myself), but it's not showing up (searched from the front page, and the only link that showed was on 10.6 from 2009).

goMac said:
Carbon doesn't run under 64 bit. At all. So this problem can't exist to begin with. This is very faulty info. It also directly conflicts with what I've heard.
Click to expand...
In the sense that there's no compatibility with the Mac GUI and programming language for 64 bit (needs Objective C, which is only Cocoa as I understand it). At least that's what I got out of this.

Assuming my interpretation of this is correct, there's a lot of legacy code that needs to be updated to Cocoa. And I don't think Apple really cares that much about 3rd party developers, especially when I think of their relationship with Adobe (but it would seem to benefit their own professional applications).

goMac said:
The delay is because in since Cocoa is the only environment that supports 64 bit, they are porting them all to Cocoa. It has nothing to do with the kernel. The decision to cut 64 bit Carbon was made well before K64 even existed.
Click to expand...
No, the Kernel's not the problem. I apologize if that's what you got out of my previous post, as that's not my meaning at all.

Simplification is (dump Carbon and K32 with it). Not necessarily aimed at users directly (marketed to them on improved performance), but developers as it's a means of additional control over 3rd party application development (maybe I shouldn't have eliminated this part from the previous post :eek:).

goMac said:
Honestly, I'd say the only thing that I see that could cause them to drop K32 is if they dropped Mach entirely, but that's a whole nother can of worms...
Click to expand...
I thought they were going to stick with Mach-O (as it can handle 32 and 64 bit x86). :confused: But you might be onto something here as well (are in fact planning to dump Mach with the rest of the PPC support in favor of something not yet revealed).

Any thoughts?
 
nanofrog said:
In the sense that there's no compatibility with the Mac GUI and programming language for 64 bit (needs Objective C, which is only Cocoa as I understand it). At least that's what I got out of this.
Click to expand...

No, this is not true.... Even most the non GUI parts don't work under 64 bit. A few select pieces survived, like parts of the resource manager.

Also, there is nothing wrong with the programming language. C, C++, Objective C... they all run under 64 bit just fine. (Carbon was C.)

64 bit Carbon actually existed at one point. I still have the build. It was cut for some other reasons, some political. Adobe was not happy at the time.

nanofrog said:
Assuming my interpretation of this is correct, there's a lot of legacy code that needs to be updated to Cocoa. And I don't think Apple really cares that much about 3rd party developers, especially when I think of their relationship with Adobe (but it would seem to benefit their own professional applications).
Click to expand...

Legacy Carbon code does need to be updated to Cocoa for 64 bit. This is correct. Generic C/C++ does not need to be updated beyond some normal maintenance. But this isn't for the reasons you seem to be assuming.

nanofrog said:
Simplification is (dump Carbon and K32 with it). Not necessarily aimed at users directly (marketed to them on improved performance), but developers as it's a means of additional control over 3rd party application development (maybe I shouldn't have eliminated this part from the previous post :eek:).
Click to expand...

Carbon has already been dumped, actually. It's not actively maintained anymore. It's just sticking around for compatibility. Carbon was pretty much dumped back in 10.5.

nanofrog said:
I thought they were going to stick with Mach-O (as it can handle 32 and 64 bit x86). :confused: But you might be onto something here as well (are in fact planning to dump Mach with the rest of the PPC support in favor of something not yet revealed).

Any thoughts?
Click to expand...

There are several kernels out there that are Mach compatible but not Mach. None of them have been adopted so far, though.

Fat binaries are also not unique to Mach-O. CFM supported them.
 
goMac said:
No, this is not true....

Also, there is nothing wrong with the programming language. C, C++, Objective C... they all run under 64 bit just fine. (Carbon was C).
Click to expand...
Nothing to do with the language itself, but the 32bit API calls to the GUI would would only work for the Carbon interface. 64 bit applications have to be implemented via Cocoa to use the GUI (as a result of Apple's decisions, such as dumping 64 bit Carbon).
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back