4 ms·

Nobody seems to be saying this here so I'll just come out and say it... Qualcomm's knee jerk reaction to press that praises Apple's platform is to point out th

Nobody seems to be saying this here so I'll just come out and say it... Qualcomm's knee jerk reaction to press that praises Apple's platform is to point out the obviously premature move to 64 bit mobile chips, since Apple does not buy Qcomm SOCs and competes with Samsung, Qcomm's biggest customer. After a little critical thinking, Qualcomm realizes that it too will shortly be selling 64 bit mobile chips because now Samsung will want to match apple spec for spec, as most Android OEMs typically do. --------------------------- As whether the move was a "gimmick" or not: The move to 64 bit would have been premature if Microsoft or an Android OEM had done it, but Apple made the right call for a few reasons: (the obvious) - ARM v8 is a new ISA, and porting 32-bit ARM kernel code to the new ISA just to abandon it in a few years would be foolish (musing)- Apple's OS people now only have to worry about one kernel code base when writing non-assembly, non performance critical code. (speculation) - Apple may consider switching some of their traditionally x86 lineup to use lower power ARM chips in the intermediate future (2-4 years) and is giving itself that option by getting their kernel ready for ARM 64. (way out there) - Apple may be planning to use their mobile chips in ultra low power server clusters, and they had to port the kernel to 64 bit before that was an option.

deleted 13y ago
[deleted]
masklinn 13y ago
In "the obvious", note that the switch to ARM64 also allows a more efficient Obj-C runtime: there are more unused bits (due to alignment and effective pointer sizes) in AArch64 than in AArch32, and more in ARM64 than x86-64. This allows the obj-c runtime to smuggle significantly more information inline in the `isa` pointer on ARM64 than on ARM32 or x86-64 (via pointer tagging): http://www.sealiesoftware.com/blog/archive/2013/09/24/objc_explain_Non-pointer_isa.html http://www.sealiesoftware.com/blog/archive/2013/09/24/objc_e... http://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html http://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and... (amongst other things, 19 bits of the pointer are now used to hold the object's reference count, for any object with less than half a million references an incref or decref is just an atomic increment or decrement of this field, instead of an indirection through a global refcount table with a bunch of locks involved)
- sorbits 13y ago
  > In "the obvious", note that the switch to ARM64 also allows a more efficient Obj-C runtime […] Why wouldn’t inline reference counts (as an extra 32 bit word in the object struct) be just as effective on a 32 bit architecture? Apple’s tagged pointer tricks are just making the best of a bad situation.
  - mikeash 13y ago
    Most definitely. If you were building a new environment from scratch, there's no reason you couldn't do the same basic stuff in a 32-bit world. Apple just couldn't do it without the architecture transition because it would break everything.
  - r00fus 13y ago
    How are extra 32bit words considered "inline"? Wouldn't this completely miss using the register for count evaluation?
mikeash 13y ago
> (musing)- Apple's OS people now only have to worry about one kernel code base when writing non-assembly, non performance critical code. iOS and Mac OS X have shared most of the kernel code for years. I doubt this makes any difference.

deleted 13y ago

[deleted]

masklinn 13y ago

In "the obvious", note that the switch to ARM64 also allows a more efficient Obj-C runtime: there are more unused bits (due to alignment and effective pointer sizes) in AArch64 than in AArch32, and more in ARM64 than x86-64. This allows the obj-c runtime to smuggle significantly more information inline in the `isa` pointer on ARM64 than on ARM32 or x86-64 (via pointer tagging): http://www.sealiesoftware.com/blog/archive/2013/09/24/objc_explain_Non-pointer_isa.html http://www.sealiesoftware.com/blog/archive/2013/09/24/objc_e... http://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html http://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and... (amongst other things, 19 bits of the pointer are now used to hold the object's reference count, for any object with less than half a million references an incref or decref is just an atomic increment or decrement of this field, instead of an indirection through a global refcount table with a bunch of locks involved)

sorbits 13y ago
> In "the obvious", note that the switch to ARM64 also allows a more efficient Obj-C runtime […] Why wouldn’t inline reference counts (as an extra 32 bit word in the object struct) be just as effective on a 32 bit architecture? Apple’s tagged pointer tricks are just making the best of a bad situation.
- mikeash 13y ago
  Most definitely. If you were building a new environment from scratch, there's no reason you couldn't do the same basic stuff in a 32-bit world. Apple just couldn't do it without the architecture transition because it would break everything.
- r00fus 13y ago
  How are extra 32bit words considered "inline"? Wouldn't this completely miss using the register for count evaluation?

mikeash 13y ago

> (musing)- Apple's OS people now only have to worry about one kernel code base when writing non-assembly, non performance critical code. iOS and Mac OS X have shared most of the kernel code for years. I doubt this makes any difference.