. . . My guess is that IBM's AIX and Linux implementations have full 64-bit APIs. The reason I say this is because of the comments that this "bridging" hardware was added in the 970, whereas the POWER3/4 have been running for years without it.
So, do I understand correctly that the 'bridge' hardware is for using 32-bit APIs for 64-bit applications, and might go away in the future, say in the 980, once all APIs are 64-bit? Also, the OS will always be able to run 32-bit applications, even without the bridge hardware, yes?
A comment off topic: this 'bridge' hardware should be reasonable evidence, in addition to the presence of AltiVec type SIMD, that IBM designed the 970 specifically for Apple. The fact that IBM sees a use for the 970 in low end servers is simply added benefit to IBM, and reason to keep IBM very motivated to develop this family of CPUs. I hear the 980 is being developed simultaneously with the Power 5. That would be a very good sign.
So, do I understand correctly that the 'bridge' hardware is for using 32-bit APIs for 64-bit applications, and might go away in the future, say in the 980, once all APIs are 64-bit? Also, the OS will always be able to run 32-bit applications, even without the bridge hardware, yes?
Thank you for the very detailed explanations.
I believe this is the case, yes. The bridge hardware described basically allows a 32-bit address space to live within the 64-bit address space, allowing 32-bit code to operate properly in a 64-bit process. This is the bridge hardware that IBM says will go away. If the 980 shows up next year I think it'll still have the bridge -- its going to take Apple a year or two to get all of their software converted, and that's if they're in a hurry.
32-bit mode support in the OS and PowerPC will never go away. It is a well defined part of the architecture.
The main reason for this use of a 64-bit bridge and 32-bit access to 64 bit archetecture by means of a 42 bit conversion is simple: Apple has a One OS strategy.
A True 64 bit operating system cannot be run on a 32 bit machine. A True 32 bit operating system cannot be run on a 64 bit machine. So the very nature of Apple creating a "64" bit operating system that will run on G5, G4, and perhaps G3, in and of itself, is proof enough that the OS is not true 64 bit.
Now with that said, what I've read of the Register report, which I enjoyed very much, my opinion is that the 64 bit implimentation of the 32 bit operating system is ingenious, superb, and will allow for the best functionality that one can have on the 64 bit hardware.
However, when Apple finally migrates everything to G5, and thus 64 bit, and all the developers have converted their programs to 64 bit, and it's native, then Apple can create the 64 bit operating system that will make the entire computer scream.
That's the beauty of this strategy. Programmers can start programming for 64 bit compatibility upon the G5 release, and Apple can wait to release the true 64 bit OS until that transition is complete and it has upgraded all its products to G5. Thus, it keeps its one OS strategy. It's more likely that we won't see Apple running pure G5 and pure 64 bit code until closer to 2010. They could even codename the OS... HAL.
. . . However, when Apple finally migrates everything to G5, and thus 64 bit, and all the developers have converted their programs to 64 bit, and it's native, then Apple can create the 64 bit operating system that will make the entire computer scream. . .
I don't believe it is as restrictive as you say here. 32-bit applications will always run on a true 64-bit operating system and G5, without the bridge. So developer do not have to convert their applications to 64-bit ever. Also, I believe OS X can be true 64 bits without all Macs having the G5. OS X could install differently for 64 and 32 bit PPC processors, just as applications can be offered that install differently on 64 and 32 bit Macs.
However, when Apple finally migrates everything to G5, and thus 64 bit, and all the developers have converted their programs to 64 bit, and it's native, then Apple can create the 64 bit operating system that will make the entire computer scream.
Don't count on it. The 32Bit->64Bit transition is not going to double your performance or something like that. 64Bit is going to give you boatloads of additional RAM you can use - but that's about all. Some applications will benefit from the longer integer types, but a lot of those calculations were even faster if offloaded to the SIMD-unit.
Besides: it is going to take time. Apple switched from 8Bit to 32Bit CPUs *20 years ago*, and back then, the expanded RAM capabilities were a godsend. Now the need is much less pressing - for quite some time, 4GB will be enough if you are not into video editing.
However, when Apple finally migrates everything to G5, and thus 64 bit, and all the developers have converted their programs to 64 bit, and it's native, then Apple can create the 64 bit operating system that will make the entire computer scream.
There is nothing "native" going on here. 32-bit mode is just as "native" as 64-bit on the 970. Apple will not and should not remove their 32-bit support because it would introduce inefficiency where it isn't needed. Going entirely 64-bit will slow down the system, not speed it up.
What Apple is going to do over the next few years is ensure that 64-bit APIs are available for all of their system software so that there is zero penalty and effort using them from a 64-bit app. Right now 64-bit apps will have to "use the bridge" to access parts of the system that are still 32-bit, but the cost of this is very very minor -- it is more of a programmer rule (and hence a potential source of bugs) that developers must follow more than anything else.
Let me get this straight- Panther will be just as ad-hoc as Smeagol as far as 64-bitness goes?
It helps me to think of it as different levels of 64 bitness. It's my understanding that Smeagol will not run 64-bit applications but Panther will. Panther is at a higher level, and ability to run 64-bit applications is a very important jump.
Let me get this straight- Panther will be just as ad-hoc as Smeagol as far as 64-bitness goes?
Smeagol isn't 64-bit anything. It uses the 970 purely in 32-bit mode and ignores the hardware's 64-bit capabilities.
Panther will be a blend of 32-bit and 64-bit. You say "ad hoc" like it means something bad (which it doesn't). Panther will be as 64-bit as Apple can make it in the time they have available. It will be sufficiently 64-bit that developers will be able to write fully 64-bit applications, which is what really matters in the end. Who cares if the OS is 64-bit as long as it gives the applications the capability to be?
Any SINGLE application can't use >4GB RAM in smeagol. If you have a program that uses more, then, you'll have to wait for a 64 bit version.
If you have 8GB of RAM with smeagol, you will still use it all divided amongst your applications, just as you do now. The only difference is that no 32-bit application can access more than 4GB for themselves.
You don't need 64-bit precision in Photoshop filters.
You do need it for more than 4gigs of files though. Hopefully this will get rid of scratch disks.
Quote:
This is similar to the 640K limit DOS suffered quite for a time.
Who would ever need more than 640k of RAM!?
Quote:
the Register
is full of crap.
Thanks Programmer that's a good sum up. I always learn something new here. All my accumulated info definitely helped today when I was "training" for Electronics in Sears today.
One thing is clear: Macs have and always will smoked PCs with RAM. And bitness. Whoohoo! Mine has more bits than yours! Take that and stuff it up your Ars.
Yes you did and it seemed quite thorough, but lamentably I still don't understand, but then again I really don't need to.
What is important is that I, a consumer, only need to know is that it won't matter if apps are 32 bit or 64 bit when run on Apple's G5 computers. I will leave it up to the developers to make my life as easy as possible.
Smeagol isn't 64-bit anything. It uses the 970 purely in 32-bit mode and ignores the hardware's 64-bit capabilities.
From what I can tell, that's not true - it does save the 64-bit registers across context switches, and an option to gcc 3.3 allows gcc to generate 64-bit code for long long's.
In addition the VM is capable of addressing all of that 8GB of memory itself; however, it still speaks 32-bit with the rest of the world (meaning no larger than a 4GB allocation per process).
From what I can tell, that's not true - it does save the 64-bit registers across context switches, and an option to gcc 3.3 allows gcc to generate 64-bit code for long long's.
In addition the VM is capable of addressing all of that 8GB of memory itself; however, it still speaks 32-bit with the rest of the world (meaning no larger than a 4GB allocation per process).
<sigh> There's always a a smartass in the crowd who comes along with details to clutter up the perspectives of the innocent non-technical types.
Okay okay... except for the geeks and techies aware of some of the arcane details, Smeagol isn't 64-bit anything. Apple could have supported up to 64 GB physical memory with the G4 (max 4 GB/process), so I don't consider that a 64-bit feature. Saving the registers and 64-bit integer registers isn't particularly useful as the number of people doing integer math who will write software that only works on the G5 is quite small.
For those more technically inclined, the bridge is discussed HERE (be forwarned this is a 10 Mb file.)
On page 267 it says,
"TEMPORARY 64-BIT BRIDGE
Processors that implement the 64-bit bridge divide the 32-bit address space into sixteen 256-Mbyte segments
defined by a table of 16 STEs maintained in 16 SLB entries."
This should keep the experts busy for a few days of light reading.
just thought I should add that I have NO CLUE as to what any of this means.
Let's expand the acronyms first.
Processors that implement the 64-bit bridge divide the 32-bit address space into sixteen 256-Mbyte segments defined by a table of 16 Segment Table Entries in 16 Segment Lookup Buffer entries.
Processors divide an address space into "pages". Each is typically 4Kbyte long. These pages can either reside in physical RAM, or be "paged out" to disk. When you try to access a memory address, the processor determines the appropriate page in a page table. The page table entry (PTE) that corresponds to the page locates the page in physical memory. Since a page is 4K, a PTE covers 12 bits of the address. On 32-bit systems you need 2^20 entries to cover the entire address space. Each entry is 8 bytes, we're talking 8MB. That's too much, so memory was divided into 256-Mbyte (or 65536-page) segments. That way, if your app uses less than 256-Mbyte, the OS can have your segment table (in 32-bit this means 16 entries times 4 bytes = 64 bytes) plus one page table (512Kbytes) rather than waste an entire 8Mbyte.
When moving to 64-bit, the PTE expands to 16 bytes while the STE expands to 16 bytes. For 32-bit address spaces you still need a 16-entry segment table that now takes 256 bytes (no big deal), but for a larger address space, you can have a lot more segments. Note that you do not have to have a full 36-bit segment table. That would require 512GByte! You can make the segment table smaller as long as your memory manager does not allocate addresses which are too high. Each page table is now 2Mbyte. How many you need depends on how much memory you use.
IMO Smeagol (10.2.7) runs in 32-bit mode. That means they have to do a few machine instructions described in section 7.9 of the book. The OS runs 32-bit. The only change is that those machine instructions were not needed by older machines.
Panther will be dual-mode. It will boot in 32-bit mode for G3 and G4, and 64-bit mode for G5. All segment and page tables will have the 64-bit format if run on a G5. Address spaces will be 32-bit, in which case they will use 64-bit segment and page tables, but only be able to allocate up to 4Gb. The processor will in this mode accept 32-bit pointers. Applications will be also able to run in 64-bit address spaces, in which case they will be able to allocate more, and will have to use different APIs.
Using different APIs sounds hard, but it really needn't be. These APIs are functions. You could have similarly named functions for 32- and 64-bit with the difference being the type of pointer they expect. 32-bit apps will be linked with 32-bit libraries, while 64-bit apps will be linked with 64-bit libraries. Therefore, no confusion should occur. Apps that use most APIs will only need to be recompiled to run 64-bit on Panther.
Thank you for the explaination, and I read your response 4 or 5 times trying to understand, but I just do not have the background. I kind of get a feel for what you and Programmer are saying but really don't understand.
But, I'm sure it will benefit a lot of the more technolgically savy people in this forum, but I have trouble just trying to remember the difference between a bit and a byte.
Comments
Originally posted by Programmer
. . . My guess is that IBM's AIX and Linux implementations have full 64-bit APIs. The reason I say this is because of the comments that this "bridging" hardware was added in the 970, whereas the POWER3/4 have been running for years without it.
So, do I understand correctly that the 'bridge' hardware is for using 32-bit APIs for 64-bit applications, and might go away in the future, say in the 980, once all APIs are 64-bit? Also, the OS will always be able to run 32-bit applications, even without the bridge hardware, yes?
Thank you for the very detailed explanations.
Originally posted by snoopy
So, do I understand correctly that the 'bridge' hardware is for using 32-bit APIs for 64-bit applications, and might go away in the future, say in the 980, once all APIs are 64-bit? Also, the OS will always be able to run 32-bit applications, even without the bridge hardware, yes?
Thank you for the very detailed explanations.
I believe this is the case, yes. The bridge hardware described basically allows a 32-bit address space to live within the 64-bit address space, allowing 32-bit code to operate properly in a 64-bit process. This is the bridge hardware that IBM says will go away. If the 980 shows up next year I think it'll still have the bridge -- its going to take Apple a year or two to get all of their software converted, and that's if they're in a hurry.
32-bit mode support in the OS and PowerPC will never go away. It is a well defined part of the architecture.
On page 267 it says,
"TEMPORARY 64-BIT BRIDGE
Processors that implement the 64-bit bridge divide the 32-bit address space into sixteen 256-Mbyte segments
defined by a table of 16 STEs maintained in 16 SLB entries."
This should keep the experts busy for a few days of light reading.
just thought I should add that I have NO CLUE as to what any of this means.
A True 64 bit operating system cannot be run on a 32 bit machine. A True 32 bit operating system cannot be run on a 64 bit machine. So the very nature of Apple creating a "64" bit operating system that will run on G5, G4, and perhaps G3, in and of itself, is proof enough that the OS is not true 64 bit.
Now with that said, what I've read of the Register report, which I enjoyed very much, my opinion is that the 64 bit implimentation of the 32 bit operating system is ingenious, superb, and will allow for the best functionality that one can have on the 64 bit hardware.
However, when Apple finally migrates everything to G5, and thus 64 bit, and all the developers have converted their programs to 64 bit, and it's native, then Apple can create the 64 bit operating system that will make the entire computer scream.
That's the beauty of this strategy. Programmers can start programming for 64 bit compatibility upon the G5 release, and Apple can wait to release the true 64 bit OS until that transition is complete and it has upgraded all its products to G5. Thus, it keeps its one OS strategy. It's more likely that we won't see Apple running pure G5 and pure 64 bit code until closer to 2010. They could even codename the OS... HAL.
Eat your heart out, Remington Typewriters.
Jaedreth
Originally posted by jaedreth
. . . However, when Apple finally migrates everything to G5, and thus 64 bit, and all the developers have converted their programs to 64 bit, and it's native, then Apple can create the 64 bit operating system that will make the entire computer scream. . .
I don't believe it is as restrictive as you say here. 32-bit applications will always run on a true 64-bit operating system and G5, without the bridge. So developer do not have to convert their applications to 64-bit ever. Also, I believe OS X can be true 64 bits without all Macs having the G5. OS X could install differently for 64 and 32 bit PPC processors, just as applications can be offered that install differently on 64 and 32 bit Macs.
Originally posted by jaedreth
However, when Apple finally migrates everything to G5, and thus 64 bit, and all the developers have converted their programs to 64 bit, and it's native, then Apple can create the 64 bit operating system that will make the entire computer scream.
Don't count on it. The 32Bit->64Bit transition is not going to double your performance or something like that. 64Bit is going to give you boatloads of additional RAM you can use - but that's about all. Some applications will benefit from the longer integer types, but a lot of those calculations were even faster if offloaded to the SIMD-unit.
Besides: it is going to take time. Apple switched from 8Bit to 32Bit CPUs *20 years ago*, and back then, the expanded RAM capabilities were a godsend. Now the need is much less pressing - for quite some time, 4GB will be enough if you are not into video editing.
Originally posted by rickag
just thought I should add that I have NO CLUE as to what any of this means.
I just explained it above.
Originally posted by jaedreth
However, when Apple finally migrates everything to G5, and thus 64 bit, and all the developers have converted their programs to 64 bit, and it's native, then Apple can create the 64 bit operating system that will make the entire computer scream.
There is nothing "native" going on here. 32-bit mode is just as "native" as 64-bit on the 970. Apple will not and should not remove their 32-bit support because it would introduce inefficiency where it isn't needed. Going entirely 64-bit will slow down the system, not speed it up.
What Apple is going to do over the next few years is ensure that 64-bit APIs are available for all of their system software so that there is zero penalty and effort using them from a 64-bit app. Right now 64-bit apps will have to "use the bridge" to access parts of the system that are still 32-bit, but the cost of this is very very minor -- it is more of a programmer rule (and hence a potential source of bugs) that developers must follow more than anything else.
Originally posted by Placebo
Let me get this straight- Panther will be just as ad-hoc as Smeagol as far as 64-bitness goes?
It helps me to think of it as different levels of 64 bitness. It's my understanding that Smeagol will not run 64-bit applications but Panther will. Panther is at a higher level, and ability to run 64-bit applications is a very important jump.
Originally posted by Placebo
Let me get this straight- Panther will be just as ad-hoc as Smeagol as far as 64-bitness goes?
Smeagol isn't 64-bit anything. It uses the 970 purely in 32-bit mode and ignores the hardware's 64-bit capabilities.
Panther will be a blend of 32-bit and 64-bit. You say "ad hoc" like it means something bad (which it doesn't). Panther will be as 64-bit as Apple can make it in the time they have available. It will be sufficiently 64-bit that developers will be able to write fully 64-bit applications, which is what really matters in the end. Who cares if the OS is 64-bit as long as it gives the applications the capability to be?
Originally posted by Programmer
Smeagol isn't 64-bit anything. It uses the 970 purely in 32-bit mode and ignores the hardware's 64-bit capabilities.
so you can't use >4GB of ram in the 10.2.7 G5s??
Originally posted by Paul
so you can't use >4GB of ram in the 10.2.7 G5s??
Any SINGLE application can't use >4GB RAM in smeagol. If you have a program that uses more, then, you'll have to wait for a 64 bit version.
If you have 8GB of RAM with smeagol, you will still use it all divided amongst your applications, just as you do now. The only difference is that no 32-bit application can access more than 4GB for themselves.
You don't need 64-bit precision in Photoshop filters.
You do need it for more than 4gigs of files though. Hopefully this will get rid of scratch disks.
This is similar to the 640K limit DOS suffered quite for a time.
Who would ever need more than 640k of RAM!?
the Register
is full of crap.
Thanks Programmer that's a good sum up. I always learn something new here. All my accumulated info definitely helped today when I was "training" for Electronics in Sears today.
One thing is clear: Macs have and always will smoked PCs with RAM. And bitness. Whoohoo! Mine has more bits than yours! Take that and stuff it up your Ars.
Originally posted by Programmer
I just explained it above.
Yes you did and it seemed quite thorough, but lamentably I still don't understand, but then again I really don't need to.
What is important is that I, a consumer, only need to know is that it won't matter if apps are 32 bit or 64 bit when run on Apple's G5 computers. I will leave it up to the developers to make my life as easy as possible.
Originally posted by Programmer
Smeagol isn't 64-bit anything. It uses the 970 purely in 32-bit mode and ignores the hardware's 64-bit capabilities.
From what I can tell, that's not true - it does save the 64-bit registers across context switches, and an option to gcc 3.3 allows gcc to generate 64-bit code for long long's.
In addition the VM is capable of addressing all of that 8GB of memory itself; however, it still speaks 32-bit with the rest of the world (meaning no larger than a 4GB allocation per process).
Originally posted by Anonymous Karma
From what I can tell, that's not true - it does save the 64-bit registers across context switches, and an option to gcc 3.3 allows gcc to generate 64-bit code for long long's.
In addition the VM is capable of addressing all of that 8GB of memory itself; however, it still speaks 32-bit with the rest of the world (meaning no larger than a 4GB allocation per process).
<sigh> There's always a a smartass in the crowd who comes along with details to clutter up the perspectives of the innocent non-technical types.
Okay okay... except for the geeks and techies aware of some of the arcane details, Smeagol isn't 64-bit anything. Apple could have supported up to 64 GB physical memory with the G4 (max 4 GB/process), so I don't consider that a 64-bit feature. Saving the registers and 64-bit integer registers isn't particularly useful as the number of people doing integer math who will write software that only works on the G5 is quite small.
Originally posted by rickag
For those more technically inclined, the bridge is discussed HERE (be forwarned this is a 10 Mb file.)
On page 267 it says,
"TEMPORARY 64-BIT BRIDGE
Processors that implement the 64-bit bridge divide the 32-bit address space into sixteen 256-Mbyte segments
defined by a table of 16 STEs maintained in 16 SLB entries."
This should keep the experts busy for a few days of light reading.
just thought I should add that I have NO CLUE as to what any of this means.
Let's expand the acronyms first.
Processors that implement the 64-bit bridge divide the 32-bit address space into sixteen 256-Mbyte segments defined by a table of 16 Segment Table Entries in 16 Segment Lookup Buffer entries.
Processors divide an address space into "pages". Each is typically 4Kbyte long. These pages can either reside in physical RAM, or be "paged out" to disk. When you try to access a memory address, the processor determines the appropriate page in a page table. The page table entry (PTE) that corresponds to the page locates the page in physical memory. Since a page is 4K, a PTE covers 12 bits of the address. On 32-bit systems you need 2^20 entries to cover the entire address space. Each entry is 8 bytes, we're talking 8MB. That's too much, so memory was divided into 256-Mbyte (or 65536-page) segments. That way, if your app uses less than 256-Mbyte, the OS can have your segment table (in 32-bit this means 16 entries times 4 bytes = 64 bytes) plus one page table (512Kbytes) rather than waste an entire 8Mbyte.
When moving to 64-bit, the PTE expands to 16 bytes while the STE expands to 16 bytes. For 32-bit address spaces you still need a 16-entry segment table that now takes 256 bytes (no big deal), but for a larger address space, you can have a lot more segments. Note that you do not have to have a full 36-bit segment table. That would require 512GByte! You can make the segment table smaller as long as your memory manager does not allocate addresses which are too high. Each page table is now 2Mbyte. How many you need depends on how much memory you use.
IMO Smeagol (10.2.7) runs in 32-bit mode. That means they have to do a few machine instructions described in section 7.9 of the book. The OS runs 32-bit. The only change is that those machine instructions were not needed by older machines.
Panther will be dual-mode. It will boot in 32-bit mode for G3 and G4, and 64-bit mode for G5. All segment and page tables will have the 64-bit format if run on a G5. Address spaces will be 32-bit, in which case they will use 64-bit segment and page tables, but only be able to allocate up to 4Gb. The processor will in this mode accept 32-bit pointers. Applications will be also able to run in 64-bit address spaces, in which case they will be able to allocate more, and will have to use different APIs.
Using different APIs sounds hard, but it really needn't be. These APIs are functions. You could have similarly named functions for 32- and 64-bit with the difference being the type of pointer they expect. 32-bit apps will be linked with 32-bit libraries, while 64-bit apps will be linked with 64-bit libraries. Therefore, no confusion should occur. Apps that use most APIs will only need to be recompiled to run 64-bit on Panther.
Thank you for the explaination, and I read your response 4 or 5 times trying to understand, but I just do not have the background. I kind of get a feel for what you and Programmer are saying but really don't understand.
But, I'm sure it will benefit a lot of the more technolgically savy people in this forum, but I have trouble just trying to remember the difference between a bit and a byte.