The 64Bit Hint

producerproducer
Posted:
in Future Apple Hardware edited January 2014
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

Comments

  • Reply 1 of 11
    macommentarymacommentary Posts: 196member
    If 64 bit support is built into the operating system, this should't be widely necessary. Look at it like the dual processor machines. ALL programs benefit from it in OSX because it is incorperated into the OS... but in OS9 (which didn't fully support dual processors) only a few programs like photoshop actually used the DP feature fully.



    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.
  • Reply 2 of 11
    *l++*l++ Posts: 129member
    Well, not quite correct.



    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.
  • Reply 3 of 11
    codewarriorcodewarrior Posts: 196member
    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.
  • Reply 4 of 11
    *l++*l++ Posts: 129member
    [quote]Originally posted by CodeWarrior:

    <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.
  • Reply 5 of 11
    codewarriorcodewarrior Posts: 196member
    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.
  • Reply 6 of 11
    daemonkdaemonk Posts: 49member
    [quote]Originally posted by CodeWarrior:

    <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>
  • Reply 7 of 11
    programmerprogrammer Posts: 3,458member
    [quote]Originally posted by Daemonk:

    <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.
  • Reply 8 of 11
    producerproducer Posts: 283member
    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?
  • Reply 9 of 11
    onlookeronlooker Posts: 5,252member
    [quote]Originally posted by Producer:

    <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.
  • Reply 10 of 11
    wmfwmf Posts: 1,164member
    Keep in mind that Apple doesn't *have* to add any 64-bit support to OS X; they could just run in 32-bit mode. So maybe 64-bit Macs could be released *before* a 64-bit OS.
  • Reply 11 of 11
    wfzellewfzelle Posts: 137member
    [quote]Originally posted by Programmer:

    <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.
Sign In or Register to comment.