64-bit support in Tiger


Apple recently posted an article on 64-bit support in Tiger. It looks like only a few libraries are available in 64-bit, so you can’t make GUI apps that use a 64-bit address space. However, you can make a 32-bit GUI app that uses your favorite form of interprocess communication to talk to a UI-less 64-bit app. This seems like a reasonable short term solution, although it will be a bit of a pain for application developers that need a larger address space for existing applications. It may require some major refactoring.


Comments (10)

  1. SBC says:

    there are other ways to boost performance in the Win platform – http://www.devx.com/amd/Article/21425

    SBC

  2. How many graphical applications need more than 32 (or 31) bits of address space? I’ve been working on the Alpha for most of the past decade, and haven’t run into a GUI component yet that required 64-bit mode: the GUI, in fact, runs both on Tru64 and Windows.

    The same seems to be true on pure Windows apps. It’s been a couple of years since I’ve been to LISA, but wasn’t it things like Oracle’s database server that pushed support of the larger memory (if only indirectly addressed) on the Xeon, and IA64 has been relegated to servers as well.

  3. Corentin says:

    This still is good news as far as I am concerned… The most CPU intensive apps I use on my Mac are all command-line only. I have no doubt that these will shortly benefit greatly from 64 bit support :-)) Excellent news for me 🙂

    Corentin

  4. Diego says:

    32 bits powerpc has a address space larger than 4 gb IIRC, perhaps it’s not so neccesary

  5. Dan Crevier says:

    I’m not sure how you could have more than a 4 GB address space with 32-bit pointers. The article states this in the first paragraph:

    Previous versions of Mac OS X have been able to take advantage of more than 4GB of system memory when running on a G5-equipped Mac, but each application was still subject to the 4GB limit imposed by a 32-bit address space

    There are two separate 64-bit issues:

    1. Performance: You should be able to take advantage of 64-bit instructions pretty easily in any app. And, IIRC Apple optimized some things like QuickTime doing this already.

    2. 64-bit address space: As a slight simplification, this lets you take advantage of more than 4 GB of physical memory in a single application. It’s becoming less and less uncommon to have that much physical memory these days, and things like digital video may push that limit.

  6. 64 bit address space also allows you to use memory mapping techniques on large objects, and let the VM system do the bookkeeping. This allows the application itself to be much simpler, and if the memory access patterns are both sparse and clustered (for example, accessing a small contiguous area of a very large array with a stride much larger than page size, or operating on a small subtree of a very large tree) you can get significant performance improvements.

    On the Alpha under Tru64, DEC used a nice trick… for 64-bit programs the whole low gigabyte was unallocated, so if you followed a wild pointer you’d trap out sooner… which makes debugging MUCH easier.

    Another thing you can do under Tru64 is map ALL shared memory segments to a unique address, so pointers to shared memory are valid across programs.

    Apple could so worse than to try and hire some of the Tru64 people away from HP, because Tru64 and Mac OS X have very similar architectures, and Tru64 is the oldest fully-64-bit UNIX out there.

  7. MacFreak says:

    Did you know that Apple already hired Tru64 people last 5 years ago.

  8. Jake Hoelter says:

    Actually, you can do greater than 4 GB of memory in a 32-bit address space, though it’s quite a hack. The x86 family, for example, supports a hardware extension called "PAE" or physical address extension on 32-bit chips. The x86 hardware adds some extra bits to track memory greater than 4 GB, and a 32-bit application can access this with some extra work (in the case of Windows, a special API available on Win Server 2003.) So yeah you still only have 32 bits of address space so you can’t address more than 4 GB at a time, but you can in fact get to more physical memory.

    Does this remind anyone of the old Apple II bank switching? You’d have a 16K "language" card, with various 4K banks you could switch in and out, so you could effectively access more than 64K of address space (though not at one time). PAE is the same idea, just a (relatively) modern version.

    I can’t recall off the top of my head if the PowerPC 750 or 74xx families support something like PAE, but there’s no reason they couldn’t have. Of course who cares now that we have the real 64-bit 970.

  9. Dan Crevier says:

    Ah yes, my Atari 8-bit had bank switching too. Those were the good ol’ days!