The "Gpul" thing sent up a red flag. Wasn't Moki mentioning something about "Ul" in previous posts? I'm searching for them right now. He was being very secretive about it. If you find it let me know. Post the thread.</strong><hr></blockquote>
Found a slightly earlier post from Moki in this thread relating to
This is good news indeed, but now comes the sticky bit?
Just how smart were the OSX programmers? Will the OS somehow be a hybrid 32/64 bit OS? Will there be 32 and 64 bit versions of all the major apps? Can Apple get by selling a 32bit machine to the general consumer and a 64bit machine to pros? How will software devs deal with this? Will they have to quickly transition most of their product lines to 64bit or will there be som way for the same version of one app to run in both environments (albeit differently) ???
PS, when will I be able to get a reasonably priced altivec capable laptop?
<strong>This is good news indeed, but now comes the sticky bit?
Just how smart were the OSX programmers? Will the OS somehow be a hybrid 32/64 bit OS? Will there be 32 and 64 bit versions of all the major apps? Can Apple get by selling a 32bit machine to the general consumer and a 64bit machine to pros? How will software devs deal with this? Will they have to quickly transition most of their product lines to 64bit or will there be som way for the same version of one app to run in both environments (albeit differently) ???
PS, when will I be able to get a reasonably priced altivec capable laptop?</strong><hr></blockquote>
Well, I OS X isn't WinNT, but NT handles 32 bit apps in their own separate memory spaces, and bundles the 16 bit apps together in a 16 bit shared memory space. I guess that's one way of doing it. Hopefully Apple will do it better. Based on what I've heard about the PPC64, it'll run 32 bit apps natively, so maybe the need for 'shared 32 bit memory space' won't be needed.
And that's just from the software side. Once 64bit machines are out there, will Apple be able to sell 32bit machines to anyone with pro app aspirations? I might fear that 32bit apps hit a dead end. Would consumers wait for 64bit machines too? As far as I can tell this will be a problem (if it really is a problem) for ALL system builders (X86 or Apple): I don't think 64bit CPU's will be going into laptops or budget machines any time soon, so we may all be living on one or another side of a 32/64 computing schizim for a couple of years... I dunno. How long after G5 debuts untill everything is 64 bit?
Well, I've checked with one of my sources, and what got him curious was the fact that the code-name is in fact correct and this thing really was planned and ready to be put into production. However, There was one minor error -- according to him the part had not taped out by November 2001. Apparently is was a bit later on.
<strong>This is good news indeed, but now comes the sticky bit?
Just how smart were the OSX programmers? Will the OS somehow be a hybrid 32/64 bit OS? Will there be 32 and 64 bit versions of all the major apps? Can Apple get by selling a 32bit machine to the general consumer and a 64bit machine to pros? How will software devs deal with this? Will they have to quickly transition most of their product lines to 64bit or will there be som way for the same version of one app to run in both environments (albeit differently) ???
PS, when will I be able to get a reasonably priced altivec capable laptop?</strong><hr></blockquote>
Don't work yourselves into a tizzy over nothing: MacOS X "64-bit" will handle 32-bit applications natively. It is a simple matter to simply check the application's info to see if it is 64-bit, and if it is to give it a 64-bit address space. Otherwise the application will get a normal 32-bit address space. Given MacOS X flexible bundling capabilities it will also be possible for developers to deliver "fat" applications which include both 32-bit and 64-bit versions (in addition to the Classic, x86, etc versions).
The arrival of 64-bit shouldn't cause any serious problems and 32-bit machines will continue to exist for some time. Why? Because 64-bit software is a rarity. Few applications need that capability and will actually run faster in 32-bit mode.
Programmer beat me to it. 32 -> 64 bit transitions are something UNIX vendors dealt with a decade ago, and usually they solved the problem by providing 32 & 64 bit libraries. For example, IRIX has /lib32 and /lib64 directories, and you choose which you're going to compile for & link against with a switch at compile time.
[[[How long after G5 debuts until everything is 64 bit?\t]]]
Well, the idea behind going to 64-bit has to do with memory issues, and as you know, RAM is becoming more and more plentiful. It won't be long before systems start shipping with 1+ Gig - o - RAM. The OS and proc. needs to be able to address this. I mentioned this in a previous post a while ago when I posted my original information that I collected about the 85xx architecture and discussed IBM's roadmap as well. I'm sure you could search for it if you wanted to have a refresh.
Another reason I mentioned in that thread was the fact that digital video eats as much RAM as you can throw at it. And since Apple is pushing digital video.... It follows .
However, a friend and contact noted some interesting points. Here is what he had to say:
\t
"I suspect that Apple will want to get a stable, debugged 32-bit system working before they tell their OS guys to really start working on the switch to 64-bits. Externally, Apple needs developers to finish the switch to OS-X before they can cram another
significant change down their throat ... Apple will not want to allow access to the instructions until they have handled the compiler ABI issues, virtual memory issues, OS interface issues, etc. For most developers I think access to
the 64-bit instructions w/o those things would cause those instructions to be of very limited use." - <anonymous>
I tend to agree with this, but it wouldn't surprise me if Apple decided to develop a 64-bit version of the OS in parallel with the 32-bit version. This way any issues that cropped up in the 32-bit version could also be addressed in the 64-bit version.
As far as speed increases, he pretty much confirmed what another trusted source said.
"Most apps will show 0 speedup, this is true of Apple/IBM or Microsoft/AMD 64-bitness."
So, it boils down to the *memory* addressing of more than 4GB so, its a forward looking design; especially if they are serious about video, 3D and servers.
And what got me wondering about parallel development of a 32-bit and 64-bit OS was due to the info I grabbed off of a Darwin development board. I posted this info a while back as well. I'll post it here again.
"PPC uses a 16 bit offset from a register to determine the load/store address. The instructions don't change, nor do their operands when you go from 32 to 64 bit. Only the data in the registers differs, which would be controlled by whether you loaded a pointer using a load word or load double word. .... cont." <end snip>
And here is the reply I received from another contact/PPC programmer at the time:
[[[Yes, the instruction format is identical. Yet there is a price for going to 64 bit: immediate values (constants embedded in machine instructions) are 16 bits wide. Filling a 32 bit register takes two instructions; filling a 64 bit register with an arbitrary bit pattern requires five instructions (synthesize two 32 bit values in four instructions, then combine them with a fifth).]]] - <end reply>
So, the code is the same -- what's needed is the *compiler* Apple and IBM may or may not have solved this problem. time will tell.
An even more interesting question is, would Apple come out with machines that are 64 bit capable, but released with a 32 bit OS? Then later on, when OS X was 64 bit ready, the people who purchased the "64 bit ready" machines would get a "free upgrade". Hopefully, Apple wouldn't relive the problems they had with SE/30's and IIci's (and other machines) not being "32 bit clean"...
[[[The arrival of 64-bit shouldn't cause any serious problems and 32-bit machines will continue to exist for some time.]]]
Possibly, but as video and 3D needs get more demanding and as long as the default RAM configurations keep increasing, I believe 64-bit will arrive sooner rather than later. Of course, not everyone will *need* 4+ GB ;-)
[[[Why? Because 64-bit software is a rarity. Few applications need that capability and will actually run faster in 32-bit mode. ]]]
Agreed. Still, if Apple is serious about *servers*.
[[[An even more interesting question is, would Apple come out with machines that are 64 bit capable, but released with a 32 bit OS? Then later on, when OS X was 64 bit ready, the people who purchased the "64 bit ready" machines would get a "free upgrade". ]]]
I suspect that Apple has thought the problem through. That said, we're likely going to have a 32-bit/64-bit hybrid platform for a while until all the kinks are worked out. It's likely that the new system (and OS whenever it arrives) will be 64-bit *clean*
The advantage to that is that since it's PPC, it will run all the 32-bit apps NATIVELY i.e., no emulation. This will buy a lot of time for developers to migrate and time for the compiler and other tools to mature.
[quote] So, the code is the same -- what's needed is the *compiler* Apple and IBM may or may not have solved this problem. time will tell. <hr></blockquote>
It might be educational to look into how IBM handles it with the existing Power4 systems. I'd imagine Apple's solution with be remarkably similar.
<strong>So, the code is the same -- what's needed is the *compiler* Apple and IBM may or may not have solved this problem. time will tell.</strong><hr></blockquote>
Well, they use gcc, so just watch the change notes. 64 bit PPC support is going in now, as is better Altivec.
The advantage to that is that since it's PPC, it will run all the 32-bit apps NATIVELY i.e., no emulation. This will buy a lot of time for developers to migrate and time for the compiler and other tools to mature.
--
Ed M.</strong><hr></blockquote>
Is this where that recent update to GCC comes in, the one addressing PPC64 and Altivec?
<strong>try a google search for "Alan Modra"</strong><hr></blockquote>
Ok. So if Red Hat and IBM are contributing back to gcc on these extensions, then clearly this product isn't going to be an Apple exclusive (assuming that Apple uses it at all...)
So, my guess is that IBM is ready to dip deeper into the linux pool with lower-end products that compete with x86. Will these boxes be able to run Mac OS X?
It's a no-brainer for Apple to tie Mac OS X to run only on their boxes, but would having a second hardware source (presumably a higher-end one) benefit adoption of OS X? I would think so at this point.
well, for what it's worth. the "pi" part was mentioned on these boards months ago. it's a term i had heard earlier this year. someone else on the board also posted about "pi" and i chimed in. so "pi" at least has some substantiation. i heard it in context of a processor bus. this is from the same source who told me of ibm working on the next gen chip rather than motorola, which i first mentioned in march or so. good to hear some more specific information about it though. sounds like it's going to be a monster.
Comments
<strong>Here's the question folks.
The "Gpul" thing sent up a red flag. Wasn't Moki mentioning something about "Ul" in previous posts? I'm searching for them right now. He was being very secretive about it. If you find it let me know. Post the thread.</strong><hr></blockquote>
Found a slightly earlier post from Moki in this thread relating to
<a href="http://forums.appleinsider.com/cgi-bin/ultimatebb.cgi?ubb=get_topic&f=1&t=002233&p=2"; target="_blank">the new IBM Foundry</a>. It's the 7th post down from the top (8/1/2002). There is some speculation on the GP-UL meaning afterwards too. DaveGee almost got it.
I know I'm late with this (sorry), but I was curious too. I remembered the speculation about the name, and couldn't find the right thread.
Just how smart were the OSX programmers? Will the OS somehow be a hybrid 32/64 bit OS? Will there be 32 and 64 bit versions of all the major apps? Can Apple get by selling a 32bit machine to the general consumer and a 64bit machine to pros? How will software devs deal with this? Will they have to quickly transition most of their product lines to 64bit or will there be som way for the same version of one app to run in both environments (albeit differently) ???
PS, when will I be able to get a reasonably priced altivec capable laptop?
<strong>This is good news indeed, but now comes the sticky bit?
Just how smart were the OSX programmers? Will the OS somehow be a hybrid 32/64 bit OS? Will there be 32 and 64 bit versions of all the major apps? Can Apple get by selling a 32bit machine to the general consumer and a 64bit machine to pros? How will software devs deal with this? Will they have to quickly transition most of their product lines to 64bit or will there be som way for the same version of one app to run in both environments (albeit differently) ???
PS, when will I be able to get a reasonably priced altivec capable laptop?</strong><hr></blockquote>
Well, I OS X isn't WinNT, but NT handles 32 bit apps in their own separate memory spaces, and bundles the 16 bit apps together in a 16 bit shared memory space. I guess that's one way of doing it. Hopefully Apple will do it better. Based on what I've heard about the PPC64, it'll run 32 bit apps natively, so maybe the need for 'shared 32 bit memory space' won't be needed.
Maybe Programmer can help here.
ahy whoo.. next.
me want gp-ul!
--
Ed
<strong>This is good news indeed, but now comes the sticky bit?
Just how smart were the OSX programmers? Will the OS somehow be a hybrid 32/64 bit OS? Will there be 32 and 64 bit versions of all the major apps? Can Apple get by selling a 32bit machine to the general consumer and a 64bit machine to pros? How will software devs deal with this? Will they have to quickly transition most of their product lines to 64bit or will there be som way for the same version of one app to run in both environments (albeit differently) ???
PS, when will I be able to get a reasonably priced altivec capable laptop?</strong><hr></blockquote>
Don't work yourselves into a tizzy over nothing: MacOS X "64-bit" will handle 32-bit applications natively. It is a simple matter to simply check the application's info to see if it is 64-bit, and if it is to give it a 64-bit address space. Otherwise the application will get a normal 32-bit address space. Given MacOS X flexible bundling capabilities it will also be possible for developers to deliver "fat" applications which include both 32-bit and 64-bit versions (in addition to the Classic, x86, etc versions).
The arrival of 64-bit shouldn't cause any serious problems and 32-bit machines will continue to exist for some time. Why? Because 64-bit software is a rarity. Few applications need that capability and will actually run faster in 32-bit mode.
It shouldn't be that big of a deal...
[ 09-16-2002: Message edited by: Gamblor ]</p>
[ 09-16-2002: Message edited by: MacJedai ]</p>
Well, the idea behind going to 64-bit has to do with memory issues, and as you know, RAM is becoming more and more plentiful. It won't be long before systems start shipping with 1+ Gig - o - RAM. The OS and proc. needs to be able to address this. I mentioned this in a previous post a while ago when I posted my original information that I collected about the 85xx architecture and discussed IBM's roadmap as well. I'm sure you could search for it if you wanted to have a refresh.
Another reason I mentioned in that thread was the fact that digital video eats as much RAM as you can throw at it. And since Apple is pushing digital video.... It follows .
However, a friend and contact noted some interesting points. Here is what he had to say:
\t
"I suspect that Apple will want to get a stable, debugged 32-bit system working before they tell their OS guys to really start working on the switch to 64-bits. Externally, Apple needs developers to finish the switch to OS-X before they can cram another
significant change down their throat ... Apple will not want to allow access to the instructions until they have handled the compiler ABI issues, virtual memory issues, OS interface issues, etc. For most developers I think access to
the 64-bit instructions w/o those things would cause those instructions to be of very limited use." - <anonymous>
I tend to agree with this, but it wouldn't surprise me if Apple decided to develop a 64-bit version of the OS in parallel with the 32-bit version. This way any issues that cropped up in the 32-bit version could also be addressed in the 64-bit version.
As far as speed increases, he pretty much confirmed what another trusted source said.
"Most apps will show 0 speedup, this is true of Apple/IBM or Microsoft/AMD 64-bitness."
So, it boils down to the *memory* addressing of more than 4GB so, its a forward looking design; especially if they are serious about video, 3D and servers.
And what got me wondering about parallel development of a 32-bit and 64-bit OS was due to the info I grabbed off of a Darwin development board. I posted this info a while back as well. I'll post it here again.
"PPC uses a 16 bit offset from a register to determine the load/store address. The instructions don't change, nor do their operands when you go from 32 to 64 bit. Only the data in the registers differs, which would be controlled by whether you loaded a pointer using a load word or load double word. .... cont." <end snip>
And here is the reply I received from another contact/PPC programmer at the time:
[[[Yes, the instruction format is identical. Yet there is a price for going to 64 bit: immediate values (constants embedded in machine instructions) are 16 bits wide. Filling a 32 bit register takes two instructions; filling a 64 bit register with an arbitrary bit pattern requires five instructions (synthesize two 32 bit values in four instructions, then combine them with a fifth).]]] - <end reply>
So, the code is the same -- what's needed is the *compiler* Apple and IBM may or may not have solved this problem. time will tell.
---
Ed M.
The typical assumption is that if 32bit apps are better than 16bit apps. Then 64bit apps are better than 32bit.
Well I'd suppose if you had extraordinary needs. Don't worry you won't see a 64bit iTunes for years if ever.
An even more interesting question is, would Apple come out with machines that are 64 bit capable, but released with a 32 bit OS? Then later on, when OS X was 64 bit ready, the people who purchased the "64 bit ready" machines would get a "free upgrade". Hopefully, Apple wouldn't relive the problems they had with SE/30's and IIci's (and other machines) not being "32 bit clean"...
Possibly, but as video and 3D needs get more demanding and as long as the default RAM configurations keep increasing, I believe 64-bit will arrive sooner rather than later. Of course, not everyone will *need* 4+ GB ;-)
[[[Why? Because 64-bit software is a rarity. Few applications need that capability and will actually run faster in 32-bit mode. ]]]
Agreed. Still, if Apple is serious about *servers*.
--
Ed
I suspect that Apple has thought the problem through. That said, we're likely going to have a 32-bit/64-bit hybrid platform for a while until all the kinks are worked out. It's likely that the new system (and OS whenever it arrives) will be 64-bit *clean*
The advantage to that is that since it's PPC, it will run all the 32-bit apps NATIVELY i.e., no emulation. This will buy a lot of time for developers to migrate and time for the compiler and other tools to mature.
--
Ed M.
It might be educational to look into how IBM handles it with the existing Power4 systems. I'd imagine Apple's solution with be remarkably similar.
<strong>So, the code is the same -- what's needed is the *compiler* Apple and IBM may or may not have solved this problem. time will tell.</strong><hr></blockquote>
Well, they use gcc, so just watch the change notes. 64 bit PPC support is going in now, as is better Altivec.
<strong><snip>
The advantage to that is that since it's PPC, it will run all the 32-bit apps NATIVELY i.e., no emulation. This will buy a lot of time for developers to migrate and time for the compiler and other tools to mature.
--
Ed M.</strong><hr></blockquote>
Is this where that recent update to GCC comes in, the one addressing PPC64 and Altivec?
edit: Dang, Johnsonwax beat me to it.
[ 09-16-2002: Message edited by: MacJedai ]</p>
oh yeah, then do some reading...
<strong>try a google search for "Alan Modra"</strong><hr></blockquote>
Ok. So if Red Hat and IBM are contributing back to gcc on these extensions, then clearly this product isn't going to be an Apple exclusive (assuming that Apple uses it at all...)
So, my guess is that IBM is ready to dip deeper into the linux pool with lower-end products that compete with x86. Will these boxes be able to run Mac OS X?
It's a no-brainer for Apple to tie Mac OS X to run only on their boxes, but would having a second hardware source (presumably a higher-end one) benefit adoption of OS X? I would think so at this point.
Discuss...