The 64Bit Hint
Wouldn't Apple want developers to make sure there Apps run well at 64 bits? releasing whatever tools/compilers and pre OS X builds necessary to test?
My point is...if there is a Hammer or Power 4 varient in the near future...developer tools and OS X builds should forshadow the release of the upcoming hardware.
Now I am an not a developer so perhaps a develper can chime in on how far in advance they would need to have knowledge of a 64bit OS/Hardware release inorder to prepare their apps for release
My point is...if there is a Hammer or Power 4 varient in the near future...developer tools and OS X builds should forshadow the release of the upcoming hardware.
Now I am an not a developer so perhaps a develper can chime in on how far in advance they would need to have knowledge of a 64bit OS/Hardware release inorder to prepare their apps for release
Comments
SO, as long as Apple does a god job of optimising OSX for 64-bit machines developers probably DON'T need release notes ahead of time.
If the OS is 64 bits and the apps are 32 bits (each app can use a maximum of 4GB), then the developpers have nothing to do. But in a true 64 bit address space, a sizeof(void *) is 8 instead of 4 in a 32 bit address space. I don't see any flag to that effect in the current tools.
* The PowerPC back end has added 64-bit PowerPC GNU/Linux support.
* Aldy Hernandez, of Red Hat, Inc has contributed extensions to the PowerPC port supporting the AltiVec programming model (SIMD). The support, though presently useful, is experimental and is expected to stabilize for 3.2. The support is written to conform to Motorola's AltiVec specs. See -maltivec.
<strong>It's already in GCC due to IBM's Linux support on POWER4. Here's a couple of interesting items on the GNU GCC page:
* The PowerPC back end has added 64-bit PowerPC GNU/Linux support.
* Aldy Hernandez, of Red Hat, Inc has contributed extensions to the PowerPC port supporting the AltiVec programming model (SIMD). The support, though presently useful, is experimental and is expected to stabilize for 3.2. The support is written to conform to Motorola's AltiVec specs. See -maltivec.</strong><hr></blockquote>
Yep, but the current tools have GCC 3.1, not 3.2.
I read on the Darwin lists that 3.3 will be the next version used by Apple.
<strong>Only the Altivec is 3.2. The 64bit PowerPC stuff is in 3.1
I read on the Darwin lists that 3.3 will be the next version used by Apple.</strong><hr></blockquote>
GCC 3.3 is tagged as being the next development line. It won't be (shouldn't be) used in production environments.
GCC 3.2 is the stable release. Unfortunately it breaks binary compatability to 3.1, just as 3.1 broke 2.96. Too bad Apple did not wait to include 3.2. This will make developers' lifes harder.
[ 08-28-2002: Message edited by: Daemonk ]</p>
<strong>GCC 3.3 is tagged as being the next development line. It won't be (shouldn't be) used in production environments.
GCC 3.2 is the stable release. Unfortunately it breaks binary compatability to 3.1, just as 3.1 broke 2.96. Too bad Apple did not wait to include 3.2. This will make developers' lifes harder.
[ 08-28-2002: Message edited by: Daemonk ]</strong><hr></blockquote>
GCC pretty much breaks binary compatibility on every release, it doesn't really matter which one Apple chooses. Better to ship Jaguar now with the best version available at the time than to delay it for some unknown length of time. The real solution to the problem would be to get GCC to stop breaking its compatibility, but its not clear to me how much of a real problem this is.
My guess is that Apple will introduce the 64-bit version of Darwin/MacOSX at next May's WWDC, and will release the 64-bit hardware and software in late 2003. Until the hardware is available developers would need a POWER machine to test with.
Also If Apple switches to say an IBM power4 like processor what does that mean for compiling tools since Motorola owns one of the compiler makers?
<strong>well when is 3.3 slated for release? assuming that is the one Apple will use next...
Also If Apple switches to say an IBM power4 like processor what does that mean for compiling tools since Motorola owns one of the compiler makers?</strong><hr></blockquote>
I'm assuming your talking about metrowerks.
GCC, and CodeWarrior realy don't have anything to do with one another. I don't see why Metrowerks would stop making CodeWarrior for Mac OS if Apple stopped using Motorolla processors. Metrowerks also makes compilers, and IDE's for Palm, PlayStation 2, Linux OS, Windows, a,d the list go's on. None of those use Motorola processors that I know of, well accept Linux.
<strong>GCC pretty much breaks binary compatibility on every release, it doesn't really matter which one Apple chooses.</strong><hr></blockquote>
That's not true, 3.1 was supposed to establish binary compatibility from then on (for a long time). Due to bugs, 3.2 will also be incompatible, but 3.2+ should be binary compatible.
[quote]<strong>Better to ship Jaguar now with the best version available at the time than to delay it for some unknown length of time. The real solution to the problem would be to get GCC to stop breaking its compatibility, but its not clear to me how much of a real problem this is.</strong><hr></blockquote>
It's enough of a problem that Apple has built 2.9.5-emulation/conversion into Jaguar. It bites developers hard since they cannot simply compile their low-level components with Jaguar and have it run on 10.1 (they have to use 2.9.5 for that). That will also mean that a lot of future software probably won't run on 10.1, hurting the people who don't want to upgrade.