Why Apple Went 64-Bit With the iPhone 5s 512
Hugh Pickens DOT Com writes "Adrian Kingsley-Hughes says it's not just because Apple likes bragging about being first and because a 64-bit processor sounds cooler than 32-bits that Apple used the 64-bit A7 chip in the new iPhone 5s. A shift from a 32-bit processor to a 64-bit part paves the way for iPhones to be fitted out with 4GB+ of RAM down the line, but more importantly the move brings iOS and OS X apps much closer. The architecture for 64-bit apps on iOS will be almost identical to the architecture for OS X apps, making it easy to create a common code base that runs in both operating systems. 'Apple has slowly been bringing iOS-like features to Mac OS for years now: think of Launchpad and Gatekeeper,' writes Sascha Segan. 'The ultimate prize, of course, would be to bring the million-plus iOS apps to Macs. Apple could do that with an ARM-compatible virtual machine on Mac hardware, but it would want the VM, the OS and the associated apps to play nicely in the much larger memory space available on Macs. That means moving the whole system over to 64 bit.' By unifying iOS and Mac OS with Xcode developer tools in a 64-bit space, Apple could once again leap ahead of Microsoft and Google, says Segan. Microsoft hasn't yet been able to leverage its desktop strengths to achieve success as a mobile OS. The 64-bit chips for Android devices aren't ready, and neither is Android itself."
Comment removed (Score:5, Interesting)
Planned obsolescence (Score:2, Interesting)
no, no, no, my computer is not a phone (Score:3, Interesting)
All of the iOS "features" that Apple has ported to my Mac have been stupid and irritating and I have disabled them (when I could).
Please, my computer is not a phone. Haven't you learned anything from Windows 8?
There is a reason that Microsoft has not been able to leverage its desktop strengths in a mobile device... it's because my computer is not a phone and it doesn't want to be a phone and I don't want it to be a phone. I want a keyboard and a mouse, not a gorilla arm and a smudged screen.
Re:RISC (iPhone) vs. CISC (OSX) (Score:5, Interesting)
Several journalists have made this mistake, such as the drivel posted here: Trusted Reviews [trustedreviews.com]
They seem to think that the register size being equal means that software written for them is somehow much more similar. In reality the CPUs and the software they run are no closer to each other than before. The main benefit of this move to the latest ARM CPU design is ironically much the same as the advantage brought by x86_64 - more registers are now available and some floating point operations are more efficient. This will translate into a small performance increase but it won't be night and day.
It's about jailbreaking. (Score:5, Interesting)
Apple's move to the 64-bit ARM platform isn't about compatibility with OSX, support for over 4G of ram (per process, the 32-bit ARM processor can handle 1TB of RAM already) or for performance reasons (the additional memory load will almost undoubtedly overpower the slight increases in the 64-bit ARM processing improvements).
If you read through ARM's announcement of it's 64-bit platform a large portion of it is dedicated to the new security layer allowing for better segmentation between applications and a more in-depth security layer in between the segments. This will allow Apple to sit a hypervisor below the kernel and protect the system from "attacks" and if we can get through the hypervisor there is an additional ARM security layer before you can run in the top processor privilege layer.
64-bit ARM isn't about anything other than preventing jailbreaking.
More intriguing possibility (Score:4, Interesting)
This analysis of the switch [cannyvision.com] presented a more intriguing idea than the one proferred here. They suggested that the switch to 64-bit is a case of Apple laying the groundwork for later devices. Specially, their thesis is that because it's ridiculous that a phone will need 4GB+ of RAM anytime soon, the chip has actually been designed with a different product in mind, such as Apple's rumored TV product. The thinking is that something designed to be on more even ground with the likes of the PS4 or Xbox One will need to match the 8GB of RAM that each of them has, and with Apple adding game controller libraries to both iOS 7 and OS X 10.9, it looks like they're paving the way for an entry into that field, perhaps with a new class of more powerful iOS devices that use your TV as a screen and run apps from the AppStore.
Re:app store lockin on top of high cost hardware w (Score:5, Interesting)
You're not important enough to add to this list.
http://www.macobserver.com/tmo/death_knell [macobserver.com]
Re:No. (Score:5, Interesting)
It's more like they didn't have much else for the iPhone 5S, just the fingerprint sensor. Everything else is either the same or a slight improvement, like the camera.
Re:Android is finished. (Score:3, Interesting)
Android is ready for x64, TFA doesn't have a clue. It's just a recompile away. In fact, because most Android apps are written in Java they will take advantage of 64 bit CPUs without even a recompile.
And apparently it isn't just a recompile away on iOS. For anyone who didn't watch the iPhone 5S announcement, one of the big things they mentioned during the presentation was "how easy it was" to enable an app for 64-bit: it took them "only two hours" to port an existing app to 64-bit!
Uh, what?! It takes me "changing a compiler switch" to do that for everything I've ever written. I can't wait to find out how Apple managed to fuck that up with iOS 7!
Re:Desperation (Score:2, Interesting)
The IPhone 5s has 1 GB RAM. That is less than 4 GB. Inescapable conclusion is that the state reason is pure spin.
You really just don't know what you're talking about. 64-bit address space enables a lot of advanced techniques, whether or not there's more than 4GB physical RAM available.
4) Removable battery
5) Expandable flash slot
Except that most people don't give a damn about a removable battery. And the expandable flash shot is actually an awful idea from the usability standpoint. A great deal of effort has gone into the design of these Mobile OSs to free the users from having to be concerned with where their files are stored, and the flash slot just messes that up.
Re:Debian (Score:4, Interesting)
Advantages and Disadvantages of 64-bit code (Score:4, Interesting)
There are advantages and disadvantages of 64-bit mode. In the case of ARM, having double the number of registers should add a noticeable improvement. The main disadvantage of using a 64-bit ABI is that now pointers consume twice as much memory and in the case of RISC processors, loading 64-bit constants into registers can take more instructions. There is ongoing work with ARM to provide a 32-bit ABI using the 64-bit mode, much like how MIPS has the N32 and N64 ABIs (most of my experience is with 64-bit MIPS but much of it applies to ARM). In the case of ARM, having twice the number of registers should make a noticeable improvement since unlike X86 most instructions don't operate on memory locations directly except via load/store.
One weakness of 64-bit ARM is the instruction set is very new and the tools are still maturing. It was not necessarily the best thought out instruction set either and the instruction binary encoding is overly complex, making a lot more work for the toolchain developers. The difference between ARM 32 and ARM 64 is far greater than the difference between X86 and X86_64.
A7 technology more for iPad? (Score:4, Interesting)
I think the A7 SoC (system on a chip) may be more intended for the iPad than the iPhone. 64-bit memory may make it possible for iPads with as much as 4 GB of RAM, which may become important as iOS apps become more and more sophisticated in future years.
Re: 64-bit BS (Score:5, Interesting)
Your washing machine doesn't even need a 32-bit processor.
You would be surprised [low-powerdesign.com] The question is, do you want to put up with 8051 weirdo nastiness or a nice clean arm design. The original 8051 was about 30K transistors, so was the ARM 2. Which would you rather program?
Since those days, transistor density increased more than a factor of a thousand, essentially wiping out the cost advantage of 8 and 16 bit processors, they all cost less than a buck. And see this coherent argument [bluewatersys.com] for why a 32 bit arm may be more efficient than an 8 bit 8051 variant: it takes way fewer cycles to get things done.
Finally, there is productivity. Quick to market counts for a lot, and low engineering costs means shorter, more agressive product cycles. The modern manufacturer just can't afford to have expensive engineers futzing around with processor limitations.
I don't know about you, but my new LG washing machine seems to put a lot of thought into what it's doing in order to get the clothes clean using the least amount of power and water, with dozens of different options. They probably saved some parts cost by implementing the motor controller in software. I would not be surprised at all to learn that they spent a buck to put a 32 bit arm core in it. My next washing machine will be on my home network and when it's done it will notify my cell phone. Probably running Linux.
Re:RISC (iPhone) vs. CISC (OSX) (Score:4, Interesting)
Between x86-32 and ARMv7, these are all the same (well, the cost of unaligned loads and stores is more on ARM). Between x86-64 and ARMv8, they are the same. This also means that you can trivially share memory-mapped data between the two. If you were to ship a laptop with some ARMv8 cores and some x86-64 cores on cache-coherent memory interface, then you could trivially translate system calls made on the ARM chip into system calls delivered to the x86-64 operating system - you'd need to tweak the call frame, but any of the data passed by pointer would be readable by the kernel (actually, this doesn't necessarily require cache coherency, as the OS X kernel always explicitly copies data in and out via some well-defined code paths). You could also use shared memory and Mach ports to communicate between the application and the window server.
In fact, given the comparatively stateless nature of the OS X window server, it would be conceivable to have the ability to dynamically switch between a window server running on the ARM core (when in low-power mode, checking email or whatever) or the x86 core (when doing real work).