Slashdot Mirror
Why Apple Went 64-Bit With the iPhone 5s
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."
If it's such a big deal in order to get the same software to run on both systems then how does the Debian project manage to bring 37 000 packages to all eight architectures that it's currently running on? Magic?
Comment removed based on user account deletion
If they wanted they could just throw their ARM chip into the Mac. Cross platform both ways. The reason why Apple went 64bit ARM is: it was time.
Help stamp out iliturcy.
I doesn't hurt Apple that this will effectively make all 32-bit iOS devices worthless in a year or so.
4GB RAM? Current iPhones have 1GB, and since they don't have real multitasking there is little need for 4GB+.
As for bringing OS X and iOS closer, clearly this guy doesn't understand what a compiler does or why the difference between 32 and 64 bit is irrelevant for porting 99.9% of apps.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
I forget how many cat versions Apple used to say was finally ready for 64 bit. I think it started in 10.2, 10.3 definitly had it. But Cocoa didn't go 64 bit until 10.5 and the kernel was still 32 bit until 10.7. So I don't know about this "designed from the ground up", more like "bolted on in the last minute."
Phones are not going to have more than 4GB or RAM any time soon.
Right, because they don't already have 2GB.
64-bit is Marketing BS at this point.
Right, because there are no algorithms, none whatsoever, not mmapped in-memory databases, not modern runtimes, which benefit from having a large address space that will not be exhausted by fragmentation. Yep, none at all.
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.
I don't read your sig. Why are you reading mine?
Several journalists have made this mistake, such as the drivel posted here: Trusted Reviews
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.
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.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
I don't want a fart app for my desktop.
I don't read your sig. Why are you reading mine?
Apple loves to be "first". They love to have something they can claim to be first on, be better on. Doesn't matter if said thing really is an improvement, they'll sell it like one and fanboys buy in to it pretty heavily.
So, here they can claim to be 64-bit and talk about how that is better. Doesn't matter that it doesn't actually help in the real world, at least at this point, they can sell it as awesome and powerful and something those other nasty, crappy, phones don't have.
In terms of app compatibility, that is all to do with APIs. 64-bit matters not at all, since ARM and x86 are completely different architectures so there WILL be a recompile, no matter what. If they put their iOS APIs on OS-X, then that can be used to port apps to it pretty easy.
So my bet is you are right, this is all marketing at this point. They can say "OMG we has 64 of t3h bits!" and use that as a selling point.
the ubuntu edge was going to have 4gb of ram, but it only got 13 million out of the 32million funding goal
I get the technical reasons why this would allow the flexibility of easily porting/running iOS apps on OS X Macs ... but I'm trying to figure out what the real benefits would be?
The vast majority of apps developed for iOS are designed to work better with the limitations of a very portable device (small screen, limited memory and disk storage, etc.). In most cases, they already have more full-featured and capable counterparts that run on regular computer operating systems.
Many times, the only reason an "app" exists for iOS (or Android) is to improve an experience that's just fine with a web browser on a Mac or PC, but winds up sub-par on a small touchscreen device. I'd put almost all of the "shopping" apps in this category. Whether it's the Amazon mobile app, eBay's mobile app, or a retailer like CVS or Target -- you'd never really care about the app in the first place if the company's web sites functioned better on a phone or tablet.
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.
These are completely different architectures, and I highly doubt portability will be easier between the two, just because one makes the jump to being native 64bit.
Emulating an ARM core on x86 is totally doable (QEMU, in fact, does it for the Android SDK's test/emulator component. I don't think anybody has an OSS iPhone clone fully working; but that wouldn't take Apple long); what I find baffling is the theory that the application being emulated would need to be 64 bit to 'play nice' with the larger memory space available to the host.
Even if Apple decided to support cross-platform binaries(and that's one hell of an 'if', Apple Loathes half-assed ports, and has so far not embraced touchscreens in desktops and laptops, so cross-platform binary support would be asking for half-assed ports in both directions); allocating one or more 32-bit processes its own happy little address space has been trivial on 64-bit OSes for ages. Hell, even pre-64-bit, PAE systems were happily slicing large quantities of RAM into 32-bit address chunks to support 32-bit processes. Since Apple makes no ARM devices with 4GB+ of RAM(indeed, they tend to ship rather on the low side compared to the pricier Android OEMs), iOS apps aren't exactly going to be starving on the desktop, and a desktop OS has no trouble carving up a larger memory space into smaller chunks.
Cortex A15 has 40 bit addressing and can access 1TB of physical RAM.
The 32 bit limit is per process.
This analysis of the switch 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.
What exactly don't you consider real about iOS 7's multitasking? Can apps run in the background? Yes, although you are supposed to do so sparingly. Some other requirement of which I'm unaware? iPhones aren't likely to have 4GB any time soon because of cost and battery use. But iPads might.
I did. The whole thing is nonsense. You don't have to enforce a single architecture to have common code. Neither do you need to have a virtual machine running the same bit-ness as the host operating system. This is just the usual kind of cluelessness that comes from a community that is proud of being stupid.
Yeah. 64-bit BS.
A Pirate and a Puritan look the same on a balance sheet.
You're not important enough to add to this list.
http://www.macobserver.com/tmo/death_knell
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!
You're funny.
Are you seriously suggesting that Apple migrates their desktop machines to hardware that's about 10 years behind the curve in terms of performance when compared to x86?
Stop swimming in the kool-aid.
A Pirate and a Puritan look the same on a balance sheet.
You are absolutely right. The whole summary doesn't make any sense at all... first of all, the Macs run 32-bit applications just fine. Second, if you can emulate a 64-bit ARM, you can emulate a 32-bit ARM. Third, phone apps would suck on a laptop or desktop.
I suspect they went to 64-bit for the simple reason that it is the direction ARM is going. This processor design is likely to show up in their lower-end products for years after it leaves their flagship device, and the sooner they go to 64-bit, the sooner they can depreciate the 32-bit stuff. Unless the 64-bit chip cost significantly more to design, produce, or unless it has a significant performance penalty, there is no reason to delay making it.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
The A7 is 64-bit because it gives apple the only phone that's capable of taking us past 4G. And to think some phones are still 3G. ;)
Android is ready for x64, TFA doesn't have a clue. It's just a recompile away.
Bullshit. Making an OS 64 bit is far more complex than a recompile. And the next Android version, Kit-Kat is not expected to be 64 bit compatible.
Android 64 bit is at least a year away.
So you would think that this new large address space will allow more complex and productive apps brought to the iPhone.
But, if you read the article, you'll see this:
But it's the iPhone that's being brought up to the same address space as the Mac, not the other way around. Interesting that Apple puts this in terms of making the Mac more like the iPhone instead.
Macs are already technically capable of running iOS apps.
Plus, and this is not a small concern, I think there are plenty of Mac users (like me) who see the notion of OSX becoming more like iOS as something of a big step in the wrong direction. Maybe Apple's purpose is not the same as the purpose of people who use Macs.
You are welcome on my lawn.
There is a depressing depreciation in total knowledge of the word "deprecation".
You don't have to enforce a single architecture to have common code.
But it makes it easier. In this case Apple will have 64-bit ARM and 64-bit Intel to maintain instead of 32-bit ARM and 64-bit Intel. I think there's a longer term strategy here. I'm not sure what it is.
Well, there's spam egg sausage and spam, that's not got much spam in it.
There's no grand scheme or plan for 64-bits vs 32-bits. They went 64-bits simply because it's the next evolution of chip design. 64-bit processing doesn't strike at a a need today but eventually it will be beneficial and even necessary so if you're going to spend millions on an ARM design you might as well make it 64-bits.
Google isn't porting an OS to 64 bit from scratch. Linux for ARMv8 probably already exists. So does GCC.
They mainly need to make sure their userspace, including java VM, still compiles on 64 bit. Then current Android application will benefit from ARMv8 without the need for a recompile.
Third, phone apps would suck on a laptop or desktop.
That's not quite true. A touch-screen iMac or Macbook would be perfectly suited for running iPad apps. I think this is a brilliant move by Apple, if they do indeed seamlessly bring the entire iOS application ecosystem into the OSX family of computers.
Better known as 318230.
32-bit can address up to 4GB of RAM. So 32-bit will be fine until they create a phone with > 4GB of RAM.
Seriously, has no one here heard of Physical Address Extension? 32-bit architectures can definitely access more than 4GB of RAM. There are MS Server 2008 editions that can access 64GB. MS uses it as leverage to get customers to buy more expensive SKUs. A single process is what is limited to 4GB on a 32-bit system.
Interesting that Apple puts this in terms of making the Mac more like the iPhone instead.
Apple did not write the speculation in TFA. They merely said it makes maintaining a common code base easier. Nothing about making the Mac more like the iPhone.
Seriously, has no one here heard of Physical Address Extension?
Yes. Let us never speak of it again.
If God forks the Universe every time you roll a die, he'd better have a damned good memory.
Seriously? You call someone else an idiot yet your post clearly shows you don't understand the difference between RAM and FLASH storage?
Apparently the phone has 1016 MB RAM.
Third, phone apps would suck on a laptop or desktop.
If only Microsoft would realize this.
Parent wasnt making an absolute statement, he was (correctly) stating that 64-bit will have almost no benefit on a cellphone for a very long time;
That statement is unequivocally wrong. It will have a benefit very soon. It is exactly what I have been waiting for, and I know other developers in the same position. I was hoping for it in 2014, getting it a year early is incredibly sweet.
...and that the author of the article has no idea what they're talking about (since ARM being 64-bit has no relevance to compatibility with a 64-bit Intel processor.
But that's not what the article said. It talked about using the "same codebase", meaning same source code, and thought it didn't state it explicitly, it sure sounded like he was implying same backend data-handling code, not UI. And yes, this is important. If you use algorithms that need a large virtual space on OS X, and you have to completely back off that and use something else on iOS, what a pain--oh, and in some cases, the iOS version is lower-performance as well because of that change. And that sucks. Having to go to lower-performance algorithms on a mobile platform is a double hit to performance.
But hey, if you don't actually have a clue of all the things a 64-bit address space enables, then the above will sound like gibberish...
Android could be 64 bit. Right now the hardware is not. It will take some coordination between Google and the OEMs to make it 64-bit. An obstacle is that the chipmakers haven't released a 64-bit ARM chip yet. Most likely it will be based on the Cortex 50 series.
Well, there's spam egg sausage and spam, that's not got much spam in it.
Not just their marketing department... I seriously doubt that ARM itself is going to develop the 32-bit platform much beyond where it is today. And if they ever decide to jump to Intel, Atom is also 64-bit.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Apple is infamous for dropping older hardware.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Yeah I'm a little confused by this statement:
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.
If anyone is well positioned for apps to run on both operating systems it's... Microsoft. They have one kernel running on phones and tablets and laptops. They also haven't arbitrarily delineated PCs and Tablets like OSX has.
You literally already can run an x86 or metro app on most windows 8 tablets. And with Metro almost all of the apps already run on ARM and x86-64. Not to mention Windows 8.1 works really well on my tablet and my home desktop. My work machine hasn't been upgraded yet but I just saw that MacDrive now supports Windows 8 so I think it's safe.
When OSX attempts to bridge the gulf between OSX and iOS it's going to run into the exact same challenge that Microsoft has in Windows 8. And like Windows 8 it'll have teething issues. The difference is that Windows has already been at it for over 2 years and it already has a 64 bit ready tablet OS with proven multi-tasking etc. I don't see how Apple is any kind of position to leapfrog Microsoft in development since Microsoft is *already there*.
Google is also well positioned with existing products that allow you to run Google Apps on x86 windows tablets. Intel is also investing a lot of money to port Android over to x86 natively for their phone x86 chips. So while a little behind Microsoft in porting their OS to a desktop environment between Intel's efforts and the Transformer book (which is very much like a desktop/laptop experience) Android could very easily cross over.
Apple could feasibly leapfrog Android if they doubled down on enabling keyboard/mouse input and OSX runtime but they can't by any definition leapfrog Microsoft which has already finished the transition.
Let's also not bring PAE into the discussion at all, since it's an x86-exclusive kludge
If ARM Cortex-A15 supports 40-bit PAE, I don't see how it's so x86-exclusive.
The whole thing sounds like a web site tech writer who doesn't understand how things work but who knows how to read press releases and repeat what marketing liaisons say.
64-bit processor will consume more power than an equivalent 32-bit version, so if the extra abilities aren't being used then it's a waste. And the extra abilities are almost all about memory addressing ranges.
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.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
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.
The article is BS, because it assumes there are no legit technical reasons to go to ARM's 64-bit standard. To name a few:
1. Twice as many general purpose registers
2. Twice as wide general purpose registers (so 4x the number of bytes in the register file)
3. Twice as many SIMD registers
4. Double-precision SIMD
5. On-chip encryption
6. Sparse address space for security
7. Memory mapping huge files (49-bit virtual address space)
8. A64 cleaned up the old instruction set quite a bit
And yes, tablets will probably have 8GB of RAM in the next couple of years. The XBox One and PS4 will both have 8GB, and Apple is rumored to be gunning for the living room soon as well, so putting this in the 5s gives them economies of scale before they even release a product.
Besides, the iPhone Simulator has always run on the Mac in x86, so most iPhone software has already shown a high degree of Mac interoperability. In short, having the bittedness in common with the Mac is probably way, way down the list for why they went 64-bit so early.
E pluribus unum
I like the idea in TFA.
First, implement an emulator to run OSX apps in a windowed environment on iOS, implementing panning and zooming to allow these apps to be viewed on mobile device.
Secondly, install a dynamo in Steve Jobs' coffin, allowing Apple to become energy self-sufficient.
When Argumentum ad Hominem falls short, try Argumentum ad Matrem
Bullshit. Making an OS 64 bit is far more complex than a recompile. And the next Android version, Kit-Kat is not expected to be 64 bit compatible.
That is true, porting objective-c code from 32 to 64 bits is tricky, and that is why Apple is doing it now. In the future when apple does need more than 4 GB of RAM in their devices, they will need to have apps that can take advantage of that. They are making 64 bit available very early so apps will be ready by then.
64 bit gives more registers and some bigger floating point operations, which marginally benefits some apps (it is not ground breaking). But the real advantage of 64 bit is the ability to address more than 4 GB of RAM, which is moot in the iPhone 5c and 5s since they only have 2 GB. So this is more about laying the foundation for future devices/apps than actually benefiting users of 5c and 5s.
Android 64 bit is at least a year away.
Sure, but the situation is very different. You see, most android Apps are not compiled to ARM. They are compiled to Dalvik, which has a bytecode that does not care if it runs in 32 bit or 64 bit. What this means is that at some point, when Google makes Dalvik 64 bit, the vast majority of the apps that run in Android will automatically be 64 bit, without even recompiling.
So unlike with iOS, Google can take its time and do the switch when it is actually useful.
Your washing machine doesn't even need a 32-bit processor.
You would be surprised 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 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.
When all you have is a hammer, every problem starts to look like a thumb.
I haven't seen any references anywhere about a 64-bit iOS
You haven't been looking in the right places (although "built specifically for 64bit architecture" probably lies somewhere between hyperbole and bullshit, given that it runs Just Fine on 32-bit machines).
more likely this has been done so when Apple releases a 64-bit version of iOS in 2-3 years
Make that "in 4 to 5 days" instead.
Author is an idiot.
'The ultimate prize, of course, would be to bring the million-plus iOS apps to Macs.
Which is what will definitely not happen, because Apple is about the only company on this planet that really understands that mobile and desktop are two different animals, with different needs and patterns of interaction.
Microsoft's "surface" isn't a fail because the hardware sucks, you know?
The ultimate prize is that developers will have an easier time writing stuff for both iOS and OS X, because they can share the backend code between the two and only have to write a new frontend.
That way, instead of getting a million crap apps that work badly on OS X, you will get a few thousand quality apps with a true OS X interface.
Assorted stuff I do sometimes: Lemuria.org
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).
I am TheRaven on Soylent News
32-bit x86 processors can address more than 4GB of RAM. The ARM specification allows for 40-bit PAE, which should support up to a terabyte of RAM. So we could get an iOS device with a 32-bit ARM processor that has 8GB of RAM; that's not an issue.
Each process will only be able to see 4GB of RAM, but right now, iOS apps get killed after using more than 256MB of RAM or so. The policy seems to be that each application can use about a quarter of the machine's RAM, so if they're keeping that trend and want a device with 16GB of RAM, they'll want a 64-bit processor, but I think that's a ways off.
Maybe Apple plans to cram a full-blown desktop system into the iPhone, Shuttleworth style. Phone personality when stand-alone, and desktop personality when docked. Not right away, of course. The two systems haven't merged yet. But down the road...
Actually, that might be a route for Microkia to take - and the new low-powered intel chips might make it feasible. If so, the desktop OEM's won't be happy. In any case, I hope Android gets there first - followed by Canonical. The interesting bit is that none of the potential players in a 'dockable phone/desktop' arena have a serious stake in desktop hardware. Apple does, but minor compared with their mobile juggernaut. Microsoft has a desktop software business, and I don't suppose they can get away with charging a $100 software premium on their phones (on top of the beefy hardware requirements) to make up for the loss of desktop Windows licenses. So maybe they'll hold back and give Samsung, Asus and Motorola a chance to shine.
Posted from my Android phone. Oh, I can change this? There, that's better...