-- re: Panther being a 64 bit OS; I highly doubt it. Most likely the kernel will be tweaked so that it works on a 64 bit processor, but other than that, I'd guess that it will be effectively 32 bit as far as all running apps are concerned
-- re: moving apps over to being 64 bit; yes, it will be easy to do, but no, I don't expect it to happen (or be possible) in the short term. This isn't a big deal; 64 bit addressing doesn't gain you anything, except in some very specific apps
-- if I were Apple, I'd first make my OS work with a 64 bit chip, but keep everything else the same. Then in a future release, I'd change the kernel a bit so that *it* can take advantage of 64 bit addressing, handing off chunks of MMU-mapped memory to the running 32 bit apps, who would never know the difference (benefit: more than 4gb of addressable RAM). Finally, down the road, I'd make it 64 bit in userland, too, for apps that take advantage of it; for those they don't, I'd run 'em in 32 bit more (for compatibility reasons, to save memory, and to not slow things down unnecessarily)
I have to respectfully disagree with you here, moki. Once Apple gets the kernel booting on the 64-bit processor their first priority is to support 64-bit userland apps, which requires saving the state of the 64-bit registers across context switches. Once that's done, the userland apps and system libraries can be recompiled with a 64-bit compiler and shipped as dual-fat executables. The system libraries are what's important here though - Apple would want to be able to claim a 64-bit OS; they remember how long it took to get the old OS PPC-native and IMHO don't look forward to a repeat of that.
Keep in mind Mach-O allows apps to be deployed for multiple architectures. The good ol' days of NeXT were quad-fat (68k, x86, SPARC, HPPA); here the OS would become double-fat (PPC 32, PPC 64). This lowers the barrier to an OS transition.
NAB is in a few weeks. The plot will thicken IF Apple announces, say an update to Final Cut Pro, but says to customers it will be available in June on a date which happens to fall AFTER the WWDC.
In the short term, I think what Apple does at NAB will determine to some extent what we may or may not see at this newly moved convention in June.
I have to respectfully disagree with you here, moki. Once Apple gets the kernel booting on the 64-bit processor their first priority is to support 64-bit userland apps, which requires saving the state of the 64-bit registers across context switches. Once that's done, the userland apps and system libraries can be recompiled with a 64-bit compiler and shipped as dual-fat executables. The system libraries are what's important here though - Apple would want to be able to claim a 64-bit OS; they remember how long it took to get the old OS PPC-native and IMHO don't look forward to a repeat of that.
Keep in mind Mach-O allows apps to be deployed for multiple architectures. The good ol' days of NeXT were quad-fat (68k, x86, SPARC, HPPA); here the OS would become double-fat (PPC 32, PPC 64). This lowers the barrier to an OS transition.
I'm going to disagree with Moki as well (imagine that!). Given that most of the underpinnings of the OS are already 64-bit ready and Apple has known that 64-bit was coming for 2-3 years at least, its not much of a stretch to imagine that they've been planning for it. GCC has 64-bit PPC support already, and most of the data structures in the Mac interfaces have been abstracted. Its possible that not all the environments will move to 64-bit right away -- perhaps Carbon or Cocoa will move later. The first pass at it might only all 64-bit pure Unix apps (i.e. no GUI support), but that still captures the important clients for 64-bit applications: servers. In the OS only the virtual address space management really needs to go 64-bit right away, so all of the drivers could stay 32-bit if necessary. A bit messy, but it would be possible if a full delivery of 64-bit wasn't ready in time. Mostly I think its important that Apple be able to say that they have a 64-bit solution, even if it labours under some limitations in the short term.
Mostly I think its important that Apple be able to say that they have a 64-bit solution, even if it labours under some limitations in the short term.
Can you elaborate some on the differences required in code?
Across the 24-bit to 32-bit transition there were 'new' opcodes. The old opcodes still worked, but you needed to use the new ones to reach past the boundaries. It's my impression that something similar happens for the ppc-32 to ppc-64 transition, but I'm not clear.
That is: you'd use a 'jump' command to access anything within the 32-bit regime, but if you needed access to more memory/far memory/whatever you'd use the 'long jump' command - which is a _different_ command (which has been defined in the original ppc definition, just unused).
What I'm saying is I'm missing why dual-FAT is a necessity. I can see why it might be a good idea for performance, but I'm missing why it's essential.
Can you elaborate some on the differences required in code?
Across the 24-bit to 32-bit transition there were 'new' opcodes. The old opcodes still worked, but you needed to use the new ones to reach past the boundaries. It's my impression that something similar happens for the ppc-32 to ppc-64 transition, but I'm not clear.
That is: you'd use a 'jump' command to access anything within the 32-bit regime, but if you needed access to more memory/far memory/whatever you'd use the 'long jump' command - which is a _different_ command (which has been defined in the original ppc definition, just unused).
What I'm saying is I'm missing why dual-FAT is a necessity. I can see why it might be a good idea for performance, but I'm missing why it's essential.
It's not essential, but there are a few things which make it really really really helpful. Once the kernel is 64-bit sane (basically involves memory management and saving the full registers across context switches), for applications to use that 64-bit address space they need to be able to allocate memory in amounts greater than that which can be addressed by a 32-bit word. Thus at least libSystem.dylib needs to be dual-fat (the dual part comes in maintaing compatability with 32-bit PPCs). Once that's done 64-bit BSD-layer apps can be compiled with a 64-bit port of GCC (shouldn't be much of a big deal, given that Linux already runs on 64-bit POWER4 for both the pSeries and iSeries).
In other words, at least the basic system libraries need to be dual-fat for 64-bit Terminal applications (such as server processes - Oracle is a biggie here). Whether Cocoa can make the jump is determined based on Carbon's ability to make the jump, given that much of Cocoa is in fact layered on top of Carbon (all Cocoa menubars, for instance, are mapped directly to Carbon menus). Unfortunately, Carbon is something I know little about. Are Carbon pointers explicitly defined to be 32-bit, or do they correspond directly to the sizeof(void*)?
It is mentioned in the context of portability on Apple's ADC pages.
I am sure that someone here can give you the link.
But Apple has 'uttered' the words 64-bit.
Quote:
Originally posted by DaveGee
In Apple's developers site it does make mention of future 64 bit computing... I can't dig up the reference but I did see it... I think someone over at ars (in their GPUL thread) linked to it.
Yeah, WWDC isn't about new products. It's about developers. Every so often it's used to show off new products, but usually it's to preview upcoming OS and hardware shifts.
The G4 was previewed so heavily because of AltiVec.
The 970 has no such revolutionary technology, and frankly, most any developer worth his/her salt will never notice a shift to 64-bit because they'll have been producing clean code in the first place. Sure, we'll see 970 information for those that need to clean up their code and make it 64-bit clean, but I don't see it requiring the in-depth sessions like the G4 did. If it gets any attention at all, it'll be in the Hardware track, with *maybe* a sneak preview of performance, but probably just as benchmark reporting.
Expect 10.3 Preview, and *maybe* a sneak look at the 970.
BS. BS BS BS. You are assuming that the only change in the next Power Mac will be the 970, and therefore a 64-bit capability.
I'd say it is time for some major architectual changes to the Power Mac platform. That doesn't mean just the CPU. How about hardware interconnection, clustering, new standards like PCI Express and Serial ATA... need I go on?
I'd say that the Power Mac update will be a lot more than just a 970.
heh -- not at all. When I told people not to expect a "G5" at the last several MacWorld shows, people were tearing me a new one...
I remember that. It was...ugly \
I do believe it would be a shame for Apple to not release a full 64 bit system soon after release. If they want to chase the Unix workstation market in a lot of areas they will need to provide that to have a chance.
I do believe it would be a shame for Apple to not release a full 64 bit system soon after release. If they want to chase the Unix workstation market in a lot of areas they will need to provide that to have a chance.
Honestly, the only reason for Apple to make their OS "64 bit" is for PR value. 99.9% of Apple's customers will not benefit AT ALL from a through-and-through 64 bit OS.
Most people have no idea what 64 bit even means when it comes to a processor, they just say "well, it is twice 32, it must be better!" -- hence for PR value, it would be good.
For anything else... very little, especially given Apple's market.
Honestly, the only reason for Apple to make their OS "64 bit" is for PR value.
But here, moki goes too far: (I would go with 90% though)
Quote:
99.9% of Apple's customers will not benefit AT ALL from a through-and-through 64 bit OS.
In the same way that most consumer purchasers understand that GHz is better than MGz, they also think that twice as many "bits" is twice as fast. They think about the Nintendo-64 marketing hype and have already bought in.
More experienced computer consumers will be aware of the steady progression in "bit-ness" from 8 bit, to 16, 32, and now 64 bits. They have already bought in to this more is more concept. This will finally justify the "Megahertz Myth" to them. (i.e. ~ 1.8 @ 64 must be twice as fast).
So for 90% of computer buyers 64-bit is mostly a PR and bragging rights benefit. Unless Apple can make OSX (Panther?) fully 64-bit for internal improvements (read that speed) we won't know the difference. Most of us will not be running 64-bit applications.
Having said all that, there are some niches that will benefit from 64 bit, and Apple has already targeted them. Apple's own products could very well be the first to benefit. Shake and Final Cut Pro come to mind.
I say take the leap, Apple! Going to 64-bit can only be positive, and being the first to offer 64 bits on the desktop is so Apple.
Honestly, the only reason for Apple to make their OS "64 bit" is for PR value. 99.9% of Apple's customers will not benefit AT ALL from a through-and-through 64 bit OS.
Apple consumer and core markets don't necessarily require 64-bit; however, their core professional markets could sure use (graphics, etc.) the memory space addressed by 64 bits.
I, on the other hand, am in the scientific community. 64-bit is quite common in this market with Sun; however, not a necessity (since floating point precision is fairly independent of CPU "bit size" now). That being said, if with the addition of 64-bit on the Mac, they give us something like a "double double" then that added precision will be a very welcome and useful addition. I have no idea if they will give us a 128-bit precision floating point arithmetic (I understand there may be hacks with Altivec to get this, but, in many of us need to move our code around CPU's and Altivec is then out of the question). If we do get that increased precision, it would be a great help for non-linear problems where machine round-off blows up in our face.
I think you are exaggerating with 99.9%, I would say 90%...
I do agree with moki that I think Apple will go conservative and release OS X working on the 970 without opening up 64-bit to userland at first. After extensive testing and developer teachings, I believe they will migrate toward a full 64-bit implementation. The move to 64-bit has not been exactly smooth for Sun and others, and Apple wants to minimize (especially while still trying to get people to move to OS X -- I cannot believe there are holdouts).
Honestly, the only reason for Apple to make their OS "64 bit" is for PR value. 99.9% of Apple's customers will not benefit AT ALL from a through-and-through 64 bit OS.
Most people have no idea what 64 bit even means when it comes to a processor, they just say "well, it is twice 32, it must be better!" -- hence for PR value, it would be good.
For anything else... very little, especially given Apple's market.
That's why I said above that we might see only partial 64-bit support in the system APIs -- e.g. only all the UNIX APIs might be available to a 64-bit app. This should be downright easy because the UNIX APIs have been 64-bit friendly for a very long time. This would allow "console apps" to be 64-bit, which captures all of the server applications and that is 99.9% of the apps which need to be 64-bit. Anybody else who needed it (say scientific visualization or video editting) could refactor their app into a client/server arrangement and get multiprocessor support at the same time. Plus this gives them the marketing advantage of being about to tout the 970 as a 64-bit machine, especially a 970-based Xserve.
Of course you know people at Apple while I don't so I'm not going to agree to buying you a beer. I might send you a registration fee for EVNova, however, unless I get too irritated by not being able to specify strings of hyper jumps in advance...
Comments
Originally posted by moki
A few random points here.
-- re: Panther being a 64 bit OS; I highly doubt it. Most likely the kernel will be tweaked so that it works on a 64 bit processor, but other than that, I'd guess that it will be effectively 32 bit as far as all running apps are concerned
-- re: moving apps over to being 64 bit; yes, it will be easy to do, but no, I don't expect it to happen (or be possible) in the short term. This isn't a big deal; 64 bit addressing doesn't gain you anything, except in some very specific apps
-- if I were Apple, I'd first make my OS work with a 64 bit chip, but keep everything else the same. Then in a future release, I'd change the kernel a bit so that *it* can take advantage of 64 bit addressing, handing off chunks of MMU-mapped memory to the running 32 bit apps, who would never know the difference (benefit: more than 4gb of addressable RAM). Finally, down the road, I'd make it 64 bit in userland, too, for apps that take advantage of it; for those they don't, I'd run 'em in 32 bit more (for compatibility reasons, to save memory, and to not slow things down unnecessarily)
I have to respectfully disagree with you here, moki. Once Apple gets the kernel booting on the 64-bit processor their first priority is to support 64-bit userland apps, which requires saving the state of the 64-bit registers across context switches. Once that's done, the userland apps and system libraries can be recompiled with a 64-bit compiler and shipped as dual-fat executables. The system libraries are what's important here though - Apple would want to be able to claim a 64-bit OS; they remember how long it took to get the old OS PPC-native and IMHO don't look forward to a repeat of that.
Keep in mind Mach-O allows apps to be deployed for multiple architectures. The good ol' days of NeXT were quad-fat (68k, x86, SPARC, HPPA); here the OS would become double-fat (PPC 32, PPC 64). This lowers the barrier to an OS transition.
In the short term, I think what Apple does at NAB will determine to some extent what we may or may not see at this newly moved convention in June.
Originally posted by Anonymous Karma
I have to respectfully disagree with you here, moki. Once Apple gets the kernel booting on the 64-bit processor their first priority is to support 64-bit userland apps, which requires saving the state of the 64-bit registers across context switches. Once that's done, the userland apps and system libraries can be recompiled with a 64-bit compiler and shipped as dual-fat executables. The system libraries are what's important here though - Apple would want to be able to claim a 64-bit OS; they remember how long it took to get the old OS PPC-native and IMHO don't look forward to a repeat of that.
Keep in mind Mach-O allows apps to be deployed for multiple architectures. The good ol' days of NeXT were quad-fat (68k, x86, SPARC, HPPA); here the OS would become double-fat (PPC 32, PPC 64). This lowers the barrier to an OS transition.
I'm going to disagree with Moki as well (imagine that!). Given that most of the underpinnings of the OS are already 64-bit ready and Apple has known that 64-bit was coming for 2-3 years at least, its not much of a stretch to imagine that they've been planning for it. GCC has 64-bit PPC support already, and most of the data structures in the Mac interfaces have been abstracted. Its possible that not all the environments will move to 64-bit right away -- perhaps Carbon or Cocoa will move later. The first pass at it might only all 64-bit pure Unix apps (i.e. no GUI support), but that still captures the important clients for 64-bit applications: servers. In the OS only the virtual address space management really needs to go 64-bit right away, so all of the drivers could stay 32-bit if necessary. A bit messy, but it would be possible if a full delivery of 64-bit wasn't ready in time. Mostly I think its important that Apple be able to say that they have a 64-bit solution, even if it labours under some limitations in the short term.
I really think Apple would want to show off that they have 64 bit and Intel does not...
We need to look good here...
Originally posted by Programmer
Mostly I think its important that Apple be able to say that they have a 64-bit solution, even if it labours under some limitations in the short term.
Can you elaborate some on the differences required in code?
Across the 24-bit to 32-bit transition there were 'new' opcodes. The old opcodes still worked, but you needed to use the new ones to reach past the boundaries. It's my impression that something similar happens for the ppc-32 to ppc-64 transition, but I'm not clear.
That is: you'd use a 'jump' command to access anything within the 32-bit regime, but if you needed access to more memory/far memory/whatever you'd use the 'long jump' command - which is a _different_ command (which has been defined in the original ppc definition, just unused).
What I'm saying is I'm missing why dual-FAT is a necessity. I can see why it might be a good idea for performance, but I'm missing why it's essential.
Originally posted by Nevyn
Can you elaborate some on the differences required in code?
Across the 24-bit to 32-bit transition there were 'new' opcodes. The old opcodes still worked, but you needed to use the new ones to reach past the boundaries. It's my impression that something similar happens for the ppc-32 to ppc-64 transition, but I'm not clear.
That is: you'd use a 'jump' command to access anything within the 32-bit regime, but if you needed access to more memory/far memory/whatever you'd use the 'long jump' command - which is a _different_ command (which has been defined in the original ppc definition, just unused).
What I'm saying is I'm missing why dual-FAT is a necessity. I can see why it might be a good idea for performance, but I'm missing why it's essential.
It's not essential, but there are a few things which make it really really really helpful. Once the kernel is 64-bit sane (basically involves memory management and saving the full registers across context switches), for applications to use that 64-bit address space they need to be able to allocate memory in amounts greater than that which can be addressed by a 32-bit word. Thus at least libSystem.dylib needs to be dual-fat (the dual part comes in maintaing compatability with 32-bit PPCs). Once that's done 64-bit BSD-layer apps can be compiled with a 64-bit port of GCC (shouldn't be much of a big deal, given that Linux already runs on 64-bit POWER4 for both the pSeries and iSeries).
In other words, at least the basic system libraries need to be dual-fat for 64-bit Terminal applications (such as server processes - Oracle is a biggie here). Whether Cocoa can make the jump is determined based on Carbon's ability to make the jump, given that much of Cocoa is in fact layered on top of Carbon (all Cocoa menubars, for instance, are mapped directly to Carbon menus). Unfortunately, Carbon is something I know little about. Are Carbon pointers explicitly defined to be 32-bit, or do they correspond directly to the sizeof(void*)?
Originally posted by Programmer
I'm going to disagree with Moki as well (imagine that!).
okay, but you owe me a beer if the first OS running on the PPC 970's is just 64 bit in a few parts of the kernel.
Originally posted by moki
okay, but you owe me a beer if the first OS running on the PPC 970's is just 64 bit in a few parts of the kernel.
Bah, you are just whining since this is the first time your words arent being worshipped, but actually let down!
Originally posted by T'hain Esh Kelch
Bah, you are just whining since this is the first time your words arent being worshipped, but actually let down!
heh -- not at all. When I told people not to expect a "G5" at the last several MacWorld shows, people were tearing me a new one...
Originally posted by Transcendental Octothorpe
It is mentioned in the context of portability on Apple's ADC pages.
I am sure that someone here can give you the link.
But Apple has 'uttered' the words 64-bit.
Originally posted by DaveGee
In Apple's developers site it does make mention of future 64 bit computing... I can't dig up the reference but I did see it... I think someone over at ars (in their GPUL thread) linked to it.
Dave
Well... Give it to me then!
Originally posted by moki
heh -- not at all. When I told people not to expect a "G5" at the last several MacWorld shows, people were tearing me a new one...
People need something to believe in..
Originally posted by Kickaha
Yeah, WWDC isn't about new products. It's about developers. Every so often it's used to show off new products, but usually it's to preview upcoming OS and hardware shifts.
The G4 was previewed so heavily because of AltiVec.
The 970 has no such revolutionary technology, and frankly, most any developer worth his/her salt will never notice a shift to 64-bit because they'll have been producing clean code in the first place. Sure, we'll see 970 information for those that need to clean up their code and make it 64-bit clean, but I don't see it requiring the in-depth sessions like the G4 did. If it gets any attention at all, it'll be in the Hardware track, with *maybe* a sneak preview of performance, but probably just as benchmark reporting.
Expect 10.3 Preview, and *maybe* a sneak look at the 970.
BS. BS BS BS. You are assuming that the only change in the next Power Mac will be the 970, and therefore a 64-bit capability.
I'd say it is time for some major architectual changes to the Power Mac platform. That doesn't mean just the CPU. How about hardware interconnection, clustering, new standards like PCI Express and Serial ATA... need I go on?
I'd say that the Power Mac update will be a lot more than just a 970.
Barto
Barto
Originally posted by moki
heh -- not at all. When I told people not to expect a "G5" at the last several MacWorld shows, people were tearing me a new one...
I remember that. It was...ugly
I do believe it would be a shame for Apple to not release a full 64 bit system soon after release. If they want to chase the Unix workstation market in a lot of areas they will need to provide that to have a chance.
Originally posted by Telomar
I remember that. It was...ugly
I do believe it would be a shame for Apple to not release a full 64 bit system soon after release. If they want to chase the Unix workstation market in a lot of areas they will need to provide that to have a chance.
Honestly, the only reason for Apple to make their OS "64 bit" is for PR value. 99.9% of Apple's customers will not benefit AT ALL from a through-and-through 64 bit OS.
Most people have no idea what 64 bit even means when it comes to a processor, they just say "well, it is twice 32, it must be better!" -- hence for PR value, it would be good.
For anything else... very little, especially given Apple's market.
from the use of 64 bit? i really dont think so!
Honestly, the only reason for Apple to make their OS "64 bit" is for PR value.
But here, moki goes too far: (I would go with 90% though)
99.9% of Apple's customers will not benefit AT ALL from a through-and-through 64 bit OS.
In the same way that most consumer purchasers understand that GHz is better than MGz, they also think that twice as many "bits" is twice as fast. They think about the Nintendo-64 marketing hype and have already bought in.
More experienced computer consumers will be aware of the steady progression in "bit-ness" from 8 bit, to 16, 32, and now 64 bits. They have already bought in to this more is more concept. This will finally justify the "Megahertz Myth" to them. (i.e. ~ 1.8 @ 64 must be twice as fast).
So for 90% of computer buyers 64-bit is mostly a PR and bragging rights benefit. Unless Apple can make OSX (Panther?) fully 64-bit for internal improvements (read that speed) we won't know the difference. Most of us will not be running 64-bit applications.
Having said all that, there are some niches that will benefit from 64 bit, and Apple has already targeted them. Apple's own products could very well be the first to benefit. Shake and Final Cut Pro come to mind.
I say take the leap, Apple! Going to 64-bit can only be positive, and being the first to offer 64 bits on the desktop is so Apple.
...
Originally posted by moki
Honestly, the only reason for Apple to make their OS "64 bit" is for PR value. 99.9% of Apple's customers will not benefit AT ALL from a through-and-through 64 bit OS.
Apple consumer and core markets don't necessarily require 64-bit; however, their core professional markets could sure use (graphics, etc.) the memory space addressed by 64 bits.
I, on the other hand, am in the scientific community. 64-bit is quite common in this market with Sun; however, not a necessity (since floating point precision is fairly independent of CPU "bit size" now). That being said, if with the addition of 64-bit on the Mac, they give us something like a "double double" then that added precision will be a very welcome and useful addition. I have no idea if they will give us a 128-bit precision floating point arithmetic (I understand there may be hacks with Altivec to get this, but, in many of us need to move our code around CPU's and Altivec is then out of the question). If we do get that increased precision, it would be a great help for non-linear problems where machine round-off blows up in our face.
I think you are exaggerating with 99.9%, I would say 90%...
I do agree with moki that I think Apple will go conservative and release OS X working on the 970 without opening up 64-bit to userland at first. After extensive testing and developer teachings, I believe they will migrate toward a full 64-bit implementation. The move to 64-bit has not been exactly smooth for Sun and others, and Apple wants to minimize (especially while still trying to get people to move to OS X -- I cannot believe there are holdouts).
Die Classic, Die!
Originally posted by moki
Honestly, the only reason for Apple to make their OS "64 bit" is for PR value. 99.9% of Apple's customers will not benefit AT ALL from a through-and-through 64 bit OS.
Most people have no idea what 64 bit even means when it comes to a processor, they just say "well, it is twice 32, it must be better!" -- hence for PR value, it would be good.
For anything else... very little, especially given Apple's market.
That's why I said above that we might see only partial 64-bit support in the system APIs -- e.g. only all the UNIX APIs might be available to a 64-bit app. This should be downright easy because the UNIX APIs have been 64-bit friendly for a very long time. This would allow "console apps" to be 64-bit, which captures all of the server applications and that is 99.9% of the apps which need to be 64-bit. Anybody else who needed it (say scientific visualization or video editting) could refactor their app into a client/server arrangement and get multiprocessor support at the same time. Plus this gives them the marketing advantage of being about to tout the 970 as a 64-bit machine, especially a 970-based Xserve.
Of course you know people at Apple while I don't so I'm not going to agree to buying you a beer. I might send you a registration fee for EVNova, however, unless I get too irritated by not being able to specify strings of hyper jumps in advance...