It's a classic industry conundrum: balancing the need to pull users forward to gain the benefit of new or more advanced technology with the damage that can be done by forcing an unwilling migration. Particularly if the chip can do one mode or the other, and neither simultaneously. Apple may well feel that for now it's gaining enough extra performance by stepping up to the 970 in 32-bit mode and that it doesn't feel that there's much more to gained by going to 64-bit mode. And, indeed, the extent to which the bridge delivers the benefits of 64-bit computing without the need to re-compile everything. How temporary 'temporary' turns out to be will depend on Apple's G5 adoption rate, and the necessity of providing a smooth migration path for developers. GCC 3.3 supports flags which allow developers to generate 970-only code, and to access 64-bit datapaths.Īs we say, IBM describes the bridge as temporary: "These resources are not to be considered a permanent part of the PowerPC architecture," it sternly warns.
As previously reported, coding for the G5 requires programmers adopt the GCC 3.3 compiler. "All applications written for 32-bit implementations will run without modification on 64-bit processors running in 32-bit mode," says IBM's documentation.Īpple's approach with Smeagol and Panther allows developers to continue working on 32-bit apps, but access to 64-bit features when their code detects it's running on a G5. This way Apple and its developers can take advantage of the 970's 64-bit addressing and datapaths without having to maintain a new codebase for the G5 alongside code intended to be run on older processors. This approach is clearly the one Apple favours, and the inclusion of the "temporary" bridge technology in the 970 may well have been made at Apple's behest. Indeed, that probably explains why Adobe is so readily able to provide G5 support in Photoshop with a plug-in which presumably replaces the app's main memory management code.
0 kommentar(er)
