• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Question about NSRange on the G5 and the future sizeof(int).
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question about NSRange on the G5 and the future sizeof(int).


  • Subject: Re: Question about NSRange on the G5 and the future sizeof(int).
  • From: Greg Titus <email@hidden>
  • Date: Sun, 13 Jul 2003 12:29:49 -0700

On Sunday, July 13, 2003, at 10:56 AM, Sherm Pendley wrote:
I think both responses missed the point of the question.

A 64-bit system can allocate huge data structures.

True.

[...]

From what I've read, I think Panther's 64-bit support will be somewhat limited. The OS itself, of course, will be able to manage more than 4GB of real RAM. GCC 3.3 will probably optimize operations on long longs to make use of 64-bit registers, which could be of tremendous value to apps that use them. But, each user-land process will run in a 32-bit virtual address space.

Exactly. Compiling with -mpowerpc64 will turn on the G5 instructions for 64-bit registers when using long longs. See Apple's technote:
http://developer.apple.com/technotes/tn/tn2086.html

(Is it TN2064 as shown in the page title, or TN2086 as shown in the URL? You decide...)

Once 64-bit userland processes are supported, I expect that the size of unadorned ints will stay consistent with the size of a pointer, as it did over the transition from 16- to 32-bit environments. Applications that made unwarranted assumptions about the size of such an int were more difficult to port, of course - for example, serialization code that assumed 2 bytes instead of using sizeof() when writing ints to disk. The same will be true in the upcoming transition from 32- to 64-bit apps.

You didn't quite finish this thought to make the answer to the original question obvious:

If this turns out to be true then the original questioner will be able to just go ahead and continue to use NSRange, since its structure members and macros/functions all work on and return ints, and those will automatically be 64-bits wide when pointers are 64-bits wide.

In short: nothing to worry about for the moment. To say anything more than that we'll have to wait to see what Apple's 64-bit programming model actually turns out to be.

Hope this helps,
- Greg
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: Question about NSRange on the G5 and the future sizeof(int).
      • From: Shawn Erickson <email@hidden>
    • Re: Question about NSRange on the G5 and the future sizeof(int).
      • From: Eric Dahlman <email@hidden>
    • Re: Question about NSRange on the G5 and the future sizeof(int).
      • From: "Kenneth C. Dyke" <email@hidden>
    • Re: Question about NSRange on the G5 and the future sizeof(int).
      • From: James Quick <email@hidden>
References: 
 >Re: Question about NSRange on the G5 and the future sizeof(int). (From: Sherm Pendley <email@hidden>)

  • Prev by Date: ABLocalizedPropertyOrLabel does not localize
  • Next by Date: Splitting a string and assigning to variables
  • Previous by thread: Re: Question about NSRange on the G5 and the future sizeof(int).
  • Next by thread: Re: Question about NSRange on the G5 and the future sizeof(int).
  • Index(es):
    • Date
    • Thread