Forgot your password?
typodupeerror
Iphone IOS Operating Systems Apple

Why Apple Went 64-Bit With the iPhone 5s 512

Posted by Soulskill
from the all-about-the-software dept.
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."
This discussion has been archived. No new comments can be posted.

Why Apple Went 64-Bit With the iPhone 5s

Comments Filter:
  • Debian (Score:5, Insightful)

    by kthreadd (1558445) on Friday September 13, 2013 @05:13PM (#44844111)

    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?

    • Re:Debian (Score:4, Insightful)

      by dkleinsc (563838) on Friday September 13, 2013 @05:19PM (#44844165) Homepage

      If I had to guess, a large number of people put in a large amount of effort. A really fine cross-compiler probably helps immensely.

      • by KiloByte (825081)

        Debian doesn't cross-compile, all architectures are required to build everything natively.

        Some packages do allow cross-compilation, and its obviously needed for bootstrapping a new arch, but that's for things you do locally rather than what gets uploaded to the archive.

    • Source distribution to users. And all the compilation and linking problems that brings.

      • by jedidiah (1196)

        You're an idiot. Debian doesn't distribute source to users.

        It's all binaries wrapped around the best package manager on the planet. It's something that Apple can't even touch despite their best attempts to try and sort of copy it.

        • To be fair, it's something that no other OS has been able to touch, that I know of. 3 Debian.
        • If you're only talking binary packages, then Debian doesn't "manage to bring 37 000 packages to all eight architectures that it's currently running on".

          Take a popular app like AbiWord, and it has 13 architectures for the binary package.

          Take the very first software in the package list thought: "0ad" it only has 4 architectures.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      If you are not making an open source application that needs to run on a lot of machines, then you can take some shortcuts.
      I develop OS X software and I make it specifically for OS X, this gives tools as a developer to use the libraries in OS X, which makes it very easy to quickly make a well behaving application.

      One of my applications was written when it when OS X was still 32 bit, this forced me to read from files using read(), while I rather use mmap() for reading from files. Using mmap() on large files r

    • by jcdr (178250)

      Actually it's a big deal: Debian is the only project on Earth that maintain so much architectures from the same code base and build system. There experience on that subject is outrageously ahead of many others projects. There have identified and implemented years before the others the need of a pure amd64 port (and not a quick /lib64 hack). There have adapted all there rules, and process to do that. There are now the only multiarch capable distribution. Many don't understand how complex it is to implement p

    • "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?"

      It *IS* a big deal. But it is also misguided.

      Apple has had an unfortunate tendency to do this backward. Rather than making apps work BOTH on iOS and OS X, instead they made OS X work more like iOS. And that's a mistake.

      As Microsoft has been learning, desktops are not tablets. Apps with interfaced designed for tablets are frustrating and difficult to use in a desktop environment.

      What they should be working on is a way to make the apps work BOTH with a tablet-optimized interface, AND a desktop-optimi

    • 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

  • by Kr1ll1n (579971) on Friday September 13, 2013 @05:16PM (#44844135)

    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.

    • by myurr (468709) on Friday September 13, 2013 @05:21PM (#44844199)

      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.

      • by TheRaven64 (641858) on Saturday September 14, 2013 @07:50AM (#44847889) Journal
        Very little iOS software is written in assembly. It's mostly written in Objective-C, with some C and C++. From the perspective of these languages, architecture differences are:
        • Size of various primitive types.
        • Alignment of primitive types.
        • Endian.
        • Ability to do unaligned loads and stores.

        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).

    • 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 f

  • No. (Score:5, Insightful)

    by symbolset (646467) * on Friday September 13, 2013 @05:16PM (#44844141) Journal
    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.
    • Re:No. (Score:5, Interesting)

      by AmiMoJo (196126) * <mojo@@@world3...net> on Friday September 13, 2013 @05:44PM (#44844413) Homepage

      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:No. (Score:5, Insightful)

        by Savage-Rabbit (308260) on Friday September 13, 2013 @08:05PM (#44845423)

        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.

        Really? I could say the same about the last two iterations of a whole gaggle of Android devices. Is the point you are trying to make that that we have reached 'Peak Smartphone'? If that is the case the obvious follow up question is: Did that just dawn on you? (because the rest of us have known this for a while now)

    • by symbolset (646467) *
      BTW. If I confused anybody there...since the 1980s you could get coprocessor boards in Apple PCs to run things like DOS and Windows on its native hardware rather than through virtualization or processor emulation - in a window. I was talking about adding such an Ax SOC system to a Mac in that way, not replacing the Intel processor with it. Replacing the processor would not give you the OSX compatibility obviously. Attempting to emulate a modern Intel processor on ARM is, of course, idiocy. Sorry about
  • Planned obsolescence (Score:2, Interesting)

    by the_scoots (1595597)
    I doesn't hurt Apple that this will effectively make all 32-bit iOS devices worthless in a year or so.
    • Re: (Score:3, Insightful)

      by zidium (2550286)

      The same way Windows 7 x64 made all Windows 7 installations and 32-bit programs worthless, huh?

      Oh...wait...

      • by jedidiah (1196)

        Windows is a legacy support platform. The old stuff doesn't just get jettisoned at the earliest opportunity because it's not shiny shiny enough. The platform as a whole is not under the tyrannical control of Microsoft to the same degree as Apple products. So people are much more free to use older equipment.

        The user is in control.

        I can choose to use 10 year old programs. Try that with the App Store model.

    • by gmuslera (3436)
      This. If new & updated apps will be only for 64bits (the market will let developers to have available both versions?) this will force people to change devices, wanting them or not.
    • by whisper_jeff (680366) on Friday September 13, 2013 @05:45PM (#44844423)

      You're right. They shouldn't have done anything to move their hardware forward. They should have just released the exact same device they did last year to ensure nothing ever became obsolete.

      And, by "you're right", I of course mean "you're a moron."

      Mod away.

  • Moronic (Score:4, Insightful)

    by AmiMoJo (196126) * <mojo@@@world3...net> on Friday September 13, 2013 @05:18PM (#44844155) Homepage

    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.

    • Re:Moronic (Score:5, Informative)

      by phantomfive (622387) on Friday September 13, 2013 @05:32PM (#44844319) Journal
      He doesn't understand. Here's a picture and bio of the guy who wrote the article [forbes.com]. He's mainly focused on hardware, as in books about assembling PCs from parts, so it looks like his career path was PC-repair-guy-to-author. He's obviously never written any substantial cross-platform software. He was looking through new iPhone documentation (which is right here [cocoachina.com]), and he saw a line that mentions it's easy to write code that is shared on iOS and OSX. He thought that was something new, he didn't realize that it's already easy, and has nothing to do with 64bit.
    • 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.
    • Software inevitably follows Moore's law. As fast as Moore's law provides the transistors, the software makes use of them.

      There's no need for more than 4GB in a phone now. But it's as inevitable as PCs needing more than 640K.

      For sure, Apple have 64 bit before they need it. Which is better than not having it ready when the time comes that they do need it.

      But there are undoubtably other reasons for 64 bit that we're not seeing yet. An Apple TV replacement with 3rd party apps (and thus a games console competit

    • If you didn't read, he says that by moving to 64 bit now, Apple can add memory later easily. Memory on smartphones is limited by cost and space. If other Android OEMs wanted to put more than4GB on their tablets or smartphones, now it would be of limited use.

      As for programs, I don't see that it makes the the porting instantaneous. They are still compiled on different architectures. Having a common code set helps Apple in other ways.

  • by mspohr (589790) on Friday September 13, 2013 @05:21PM (#44844197)

    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.

    • Exactly. The hardest part about 'unifying' iOS and OSX isn't the number of bits, it's getting the UI correct. If it were easy, then Apple would have done it in the initial iPhone.

      After all, the core OS is essentially the same between iOS and OSX right now (both Mach kernels with a unix userland).
      • by Guy Harris (3803)

        After all, the core OS is essentially the same between iOS and OSX right now (both Mach kernels with a unix userland).

        (Well, to be a bit more accurate, Mach+BSD kernels with a (BSD-flavored) Unix userland; it's not as if section 2 of the manual is implemented atop some non-Unixy Mach system call layer - the lowest layers of the kernel are Mach-based (the osfmk source directory), but the networking stack and VFS layer are largely BSDish, and the process management is BSDish processes, and pthreads (and threads as used by GCD), implemented atop Mach tasks and threads (all the bsd source directory), and the hardware device dr

    • by glennrrr (592457)
      How have you been disabling Core Animation? A library developed for the iPhone and brought to the Mac and now the backing for every view on screen. MapKit, notification center, core location... There are a huge number of frameworks common to both iOS and OS X, and OS X benefits greatly from the engineering effort made to optimize the code both for performance and energy usage.
  • If you're virtualizing ARM, making it 64-bit just makes it harder. 64-bit CPUs have access to all the 32-bit instructions you need. It's still virtualized, though.

  • by King_TJ (85913) on Friday September 13, 2013 @05:25PM (#44844225) Journal

    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.

  • by Anonymous Coward on Friday September 13, 2013 @05:28PM (#44844267)

    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.

    • by dfghjk (711126)

      Running iOS on top of a hypervisor seems incredibly unlikely when the goal is to use the least power possible, especially in a heterogeneous processor environment that the 5S just introduced. Not only is this wrong and stupid, but Apple doesn't care about jailbreaking that much anyway, nor would the hypervisor itself be immune to jailbreaking attacks.

      No surprise that some conspiracy theorists joined in on your comment though. No shortage of desire to upvote uninteresting perspectives.

  • Some think it's due to the new AppleTV [1] coming out (which may require more addressable memory >4GB - silly IMHO, PAE type extensions can make addressing more than 4GB easy for 32bit architectures - Intel did this in the 90s). That same article even mentioned the iWatch.

    Another is saying it's performance related. And then there's the TFA which implies iOS/OSX synergy.

    Personally, I think it's none of the above. It's just a marketing data point, and lays very important groundwork for future releases.

    • I don't understand how you can claim 64bit as innovation, especially when it isn't being used in a way that the old CPU was.

  • by viperidaenz (2515578) on Friday September 13, 2013 @05:34PM (#44844343)

    Cortex A15 has 40 bit addressing and can access 1TB of physical RAM.

    The 32 bit limit is per process.

  • by Anubis IV (1279820) on Friday September 13, 2013 @05:36PM (#44844355)

    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.

  • I'm sure there's some reason like battery life or whatever but more than 64bits I want virtual memory.

    Go to a heavy webpage like scrolldit.com on your tablet/phone, scroll down a few pages, watch the browser crash. Go get a P4 with 256meg of ram, view the same page on a desktop browser (VM will do). Runs just fine. Why? Virtual memory.

    I ran NT4 and 3DSMax on a machine in 1995. They claim my iPhone/Android/iPad/Tablet has more power but it can't run 3DSMax nor could it compile a large app. Why? No Virtual me

    • by MrEricSir (398214)

      Um, what the hell are you talking about? iOS has had a complete implementation of virtual memory since day one.

  • 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. ;)
  • by JoeyRox (2711699) on Friday September 13, 2013 @06:08PM (#44844621)
    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.
  • by AaronW (33736) on Friday September 13, 2013 @10:32PM (#44846189) Homepage

    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.

  • by MtViewGuy (197597) on Friday September 13, 2013 @10:38PM (#44846227)

    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.

  • idiot (Score:4, Informative)

    by Tom (822) on Saturday September 14, 2013 @04:25AM (#44847305) Homepage Journal

    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.

  • by dhasenan (758719) on Saturday September 14, 2013 @09:28AM (#44848207)

    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.

The flow chart is a most thoroughly oversold piece of program documentation. -- Frederick Brooks, "The Mythical Man Month"

Working...