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."
Phones are not going to have more than 4GB or RAM any time soon. 64-bit is Marketing BS at this point.
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?
The vast majority of which will be horrible on OS-X due to being designed solely for a touch interface.
Having iOS and OS-X be close together to ease development for both platforms is good but expecting the same program to run well on both isn't.
Some changes will need to be made for the keyboard and mouse versus fully touch interface as well as the difference in screen resolutions.
This isn't going to make a magic pill to port them all over flawlessly.
Comment removed based on user account deletion
iOS and OS X were designed from the GROUND UP to be 64 bit. Contrast this to Android which is still mired in decades old technology that nobody wants any more. Now that Apple has fully covered the market sections with both low and high end phone AND tablets, there is basically no where for Android left to go and it is only a matter of time before you start seeing Android's marketshare going down the tubes. Every one of my hardcore techy friends is already dumping their Android phones for the iPhone 5C and 5S, so its just a matter of time.
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'm sure marketing was a big reason. They didn't seem to have much else to offer with their latest phone.
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.
Mmmm, that 6th grade sentence structure. Stay in school, kiddies. Make sure you don't wind up a Slashdot editor. That's like the McDonalds Drive-Thru of tech blog jobs.
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.
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.
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.
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.
I can't think of a single iOS app that would be useful to run, and doesn't already exist on a Mac. And I'm not talking about app versions of webpages, like ESPN or Pizza Hut. If you can think of one, please list it here.
First, most iOS apps tend not to have requirements that would make them rely on word sizes, and ones that do (say ones that transform image data as RGBA buffers) can usually be written in an architecture independent way by using fixed-width type primitives. So the idea that you would write an app that only works with 64bit words doesn't seem sound. All you have to do to run an existing app on the new 64bit iOS simulator is to recompile it and in most cases it will run just fine.
Secondly, when the iPad was first released, developers were given a big, fat warning "this is not a big iPhone, it's a completely different UI paradigm, enough to make you want to rethink your design." This in spite of the iPad being a mobile device with a touch interface, like the iPhone. Desktops and Laptops are far off from this UI paradigm and it's hard to imagine Apple wanting to run iOS apps on Mac OS more or less unmodified.
32-bit addressing fits just fine in 64-bit memory space, and the emulator needs to translate the syscalls anyway, so there's not really any benefit to doing this...
On the contrary, if the emulated applications were only 32-bit, the JIT emulator has plenty of scrap space in a 64-bit system to throw its own memory without needing to do magic to avoid overlapping.
Really, I don't see any need for 64-bit addressing on portable devices today; it's only important if a single application needs more than that and can't handle some memory banking tricks. At the same time, it also means applications need to waste more memory for all their pointers, so it doesn't go as far.
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. Assuming like the difference between x86 and AMD64, there may be additional registers or other architectural performance improvements, it both makes current (new) hardware faster and more scaleable, and gives Apple options on where they can strike next (ie, nothing specific at all).
Maybe, given Phil Schiller's more macho, confrontational, attitude ("can't innovate my ass"), Apple just presented it to swing their big ones in the face of Samsung/Moto/Google/etc?
Make sure everyone's vote counts: Verified Voting
Well programmed application should switch over to 64bit without a single code change, and same goes for 64bit application compiled to run on 32bit. There might be performance improvement if you use lot of 64bit address, so moving to 64bit make sense, but for a cell phone, it far from a requirement for the moment.
But is it bad to switch to 64bit, I don't think so... But it no big deal to do it neither.
The real reason to do this switch over is so apple will bundle 64bit A whatever chip into their next line of laptop / desktop. So they can have super long battery life in 'low' requirement mode, and switch super quickly to the full OS in a snap. This will make it easier to interconnect both system if they are both 64bits (Maybe even tap to the data/memory storage directly... So let say you watch a video, it can switch online irc/IM checking process to the ARM processor and use the arm processor to do the disk to hardware video decoder for the video... When an event occur, the arm can wake up the main intel processor and switch the process to it. So sharing the same address space will make it possible to share the same ressources.
They'll "leap ahead of Microsoft and Google" sometime after they figure out that they need to dump Objective-C and allow a memory-managed runtime to be a first-class citizen in their OSes.
The day I can write a natively-launchable MacOS X or iOS app in .Net/Mono or Java is the day Apple finally wins that fight. Until then, we're all stuck running mono whateverMyAppIsNamed to get things to launch in OSX, and iOS is just out of the question. Interesting note: they added kernel hooks in OSX for this feature in 10.5, and iOS has had it since day 1. They just don't use this functionality.
Apple has already tacked the transition of RISC to CISC when the took OSX from PowerPC to x86. An self sourced 64-bit SOC would allow them to no longer be dependent on the Intel CPU monopoly for their laptop, desktop, server offerings.
Cortex A15 has 40 bit addressing and can access 1TB of physical RAM.
The 32 bit limit is per process.
Gee, a common code base between mobile and desktop? Too bad the shitheads at Microsoft weren't in this right frame of mind when they created the abomination known as WinRT. Have you tried sharing .NET code between WP8 and the desktop? It's almost impossible.
app store lockin on top of high cost hardware will kill mac os.
It's bad that lock down the hardware as much as they do but to add software lock down as well?
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.
You're not important enough to add to this list.
http://www.macobserver.com/tmo/death_knell
Apple has transitioned 32 -> 64 bit and RISC -> CISC already with OS X, so at this point virtually all processor-dependant code has been abstracted away. They could switch the Mac Pro to a 128 core 32 bit ARM chip—or the iPhone to an Intel 64 bit chip—and all you would have to do is recompile. So yes, the transition will be easy.
Regardless, it's 2013. If you're writing assembly or ultra low-level C and you aren't simultaneously writing generic fallbacks, then you're basically "doing it wrong."
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 memory.
Note: I know scrolldit is not and important site but there are plenty of sites that will kill your mobile browser usually because it runs out of memory.
Some other points about x86 vs x86_64 there is an overhead to using 64bit (hence people wanting the x32 abi). In all likely hood this is more about being a precursor to the Mac line moving to ARM chips.
Welcome the NEW! 27 inch iPhone!
“He’s not deformed, he’s just drunk!”
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.
Apple has transitioned 32 -> 64 bit and RISC -> CISC already with OS X
Intel chips have been RISC internally for so long that your ignorance isn't even funny. The whole RISC vs. CISC thing blew over when I was still in short trousers!
They could switch the Mac Pro to a 128 core 32 bit ARM chip—or the iPhone to an Intel 64 bit chip—and all you would have to do is recompile.
Yeah... and if you wish to make an Apple pie from scratch all you would have to do first is invent the Universe.
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. ;)
I'm running 32 bit applications on macosx without problem (Dropbox + uTorrent). Where do these experts take their clueless arguments?
Oh great, fat sloppily coded apps on my cell that run slow and are made by people with no idea that they have to get along with everyone else.
Just what I need.
It's like the 2/3 of apps on the store that are basically wrappers around garbage.
That said, this is why I'm looking forward to the iPhone 6, not the 5s.
-- Tigger warning: This post may contain tiggers! --
Infinity Blade. Now, it'd be pretty hard to play it in a macbook pro.
Right?
Next thing you know you'll want it to talk to the iWatch.
-- Tigger warning: This post may contain tiggers! --
Apple is most likely going to introduce a system where the display is iOS like an iPad, and the rest of the system is Mac.
There are several options on how they can do this. They can have a separate machine on the display, with ARM/Memory, to keep main CPU powered off when not in use. They could have everything operate from a single x86 cpu like a laptop. They could have both ARM/x86 CPU's sharing a common memory, and so on.
Eventually they will merge, but whatever they do they will have the experience of Windows 8's failures/success to build upon.
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.
IPv6
In the land of the blind, the one-eyed man is king.
Apple needs to not only offer more robust software (and hardware) but you people need to support legacy software all the way back to MacOS 1.0 CLASSIC and iOS 1.0. You should support 68K, PPC, Rosetta, etc. Frankly you should even support the original Apple II and I, the III, the Lisa. Heck, throw in CPM, DOS and Windows as well. All under the same roof. Just make software work. There is a tremendous amount of wonderful legacy software, especially in the education field but also in entertainment and small business that does not work anymore because Apple abandoned it. Bad Apple, bad apples. Apple has the manpower, the money and the code to make this all work. Just do it.
The register pressure they are experiencing now is fairly low so more will help, but it won't be as big a deal as with x86-64.
There is far more likely to be a drop in performance due to increased pointer sizes (poorer cache utilization and increased memory footprint).
OMG! ROTFLMAO! Convergence, with a vengeance!
I used ARM in 1987 to emulate x86 running MS-DOS 3 at 8088/PC-XT speed (in the 80286/PC-AT era). I used it to compile Modula-2 assignments and to edit WordPerfect documents.
Most of my friends didn't believe this was even possible ("Yeah, my Mac/Amiga/MSX can also read PC floppies." - "I'm not talking about merely reading the disk format, I'm talking about emulating the complete PC.") until I showed them.
Archimedes PC Emulator documentation (PDF).
I really need a flashlight app on my iMac.
The IPhone 5s has 1 GB RAM. That is less than 4 GB. Inescapable conclusion is that the state reason is pure spin. Let's be honest, Tim Cook couldn't think of any actual innovation to build into the phone so doubling the processor width and increasing the battery size is as far as his paper pusher imagination could take him. Face it, Tim Cook is an operations guy, not a visionary.
What Apple absolutely needed to do this time was:
1) Not a product refresh! A new model please.
2) Bigger screen... duh.
3) Banish the dot-for-dot resolution albatross that ties ios products to multiples of 640 horizontal resolution
For extra credit:
4) Removable battery
5) Expandable flash slot
Apple's final score: zero for five. Better luck next time.
When all you have is a hammer, every problem starts to look like a thumb.
In all likely hood this is more about being a precursor to the Mac line moving to ARM chips.
The day Mac can run RISC OS, I'll buy one!
Intel chips are RISC as well, the CISC is bolted on top for compatibility reasons.
Custom electronics and digital signage for your business: www.evcircuits.com
Any idea to the contrary is absurd. It's just a matter of Apple releasing iMacs and MacBooks with it.
They think that it is much, MUCH faster and more efficient than that nasty x86 and ARM could make desktop CPUs that would crush Intel, if only they wanted to or thought there was a market. So Apple-ARM fans want to see Apple move to ARM so that Apple can once again be "faster" than those evil PCs.
A big part of the Apple fanboy identity was that Macs were faster and better because of their different CPUs. Didn't matter how manifestly wrong that was becoming (particularly near the time when they transitioned), they had contrived benchmarks to prove that to themselves and it made them happy. They got real upset when the transition to Intel leaked. In fact, some came up with elaborate fantasies that Intel was going to release a new "Core X" chip just for Macs that was faster and more efficient.
So when you have someone who;s both an ARM fanboy, and thinks ARM has some magic juju that Intel doesn't (and for some reason just doesn't use that on bigger CPUs) and a Mac fanboy who wants Apple to be different and better, well you get them thinking Apple should stick an ARM CPU in their desktop.
Apple doesn't need a large market share to be MORE profitable then other companies. It will stifle Apple's market share, but increase their profitability.
Spelling and Grammar errors have been added to this post for your enjoyment
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.
One problem is that Apple has lagged in implementing a lot of HTML5 features in Safari for iOS, even when the feature would apply better to a handheld device than to a Mac. One of these features is the getUserMedia draft, which gives the user a button to turn on the camera and let the web site take pictures of things. Taking pictures is essential for scanning barcodes inside an application, such as price-checking a product in a store to see if it'd be cheaper on Amazon.
Do you think a phone will have a single process that will need more than 4GB of RAM anytime soon?
Phones and popular tablets don't multitask the same way desktop PCs do. Phones and popular tablets tend to have only one application running at once.. Unless you plan to split a single app into multiple processes (does iOS even allow this?), you can't make use of all 8 GB of RAM with only 4 GB per process unless you're devoting about 3.5 GB to caching the flash memory.
I don't think you understand how pervasive the use of Core Animation is throughout the operating system. Do you ever, for instance scroll a view? Move a window, drag an icon, update some onscreen text? Does it do so smoothly without you noticing it much. Do you remember how horrible it used to be to resize a window on OS X, and how now, it's pretty darn smooth? Well that is all running through the Core Animation compositing engine, which was developed so that the iPhone GUI would be smooth.
Debian is the only project on Earth that maintain so much architectures from the same code base and build system.
Don't forget NetBSD.
I don't know whether NetBSD has more archs than Debian (and refutes your statement), nevertheless still worth mentioning.
(yeah yeah, Netcraft etc.)
The whole RISC vs. CISC thing blew over when I was still in short trousers!
Precisely my point. Unless you write assembly, you don't even need to think about it.
Yeah... and if you wish to make an Apple pie from scratch all you would have to do first is invent the Universe.
Eh? I've moved tens of thousands of lines back and forth between iOS and MacOS, 32bit to 64 bit. It's essentially painless. Did you have an actual point?
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
Right now it's either on the device or in the cloud. And users have every right to be concerned because unless one subscribes to broadband at home and happens to be at home, files in the cloud are limited to a couple GB up or down per month. Does the OS attempt to hide whether files are in iCloud vs. Dropbox vs. Google Drive vs. the service formerly known as SkyDrive? If not, then inserting a memory card could be handled like logging in to one of these online storage services.
Come on, this is not news for nerds or stuff that matters, it's uninformed technical speculation from some guy who apparently knows nothing about CPUs and operating systems.
IOS runs on ARM, OSX runs on x86, that's a pretty much bigger leap than 32 vs 64-bit. And saying android is not ready for 64-bit demonstrates the authors knows nothing about android and linux and I won't event waste my time finding links to the first x86-64 ready kernel that was released almost 10 years ago.
Yep, I'm sure Apple will get right on that.
Whilst the execution engine in an x86 chip may be RISC (or RISC-like) code running on the chip is well and truly CISC - programs running on x86 have no access to the low-level RISC features.
Specialist Mac support for creative pros, Melbourne
A 32-bit device can address 48-bit memory addresses with PAE.
Provided you're willing to split your application up into hundreds of processes, each responsible for managing a few GB of RAM.
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.
I think this is pretty simple: Next year, the only phone that Apple sells that's 32-bit will be the A6 5C.
The 6C and 6S will run A7 and A7x/A8 chips respectively.
The year after THAT, the 5C will be EOL. The 5S or equivalent will be sold as the bottom-end phone. This means that in less than 3 years, Apple can have a line-up of phones that are still receiving full OS updates but only have one OS code line.
The 5C will probably be officially cut from updates for iOS X. The 5S will still get them. At that point, they can do whatever they want. The devices of that year or the next will probably be using 4GB of RAM. It'll be both cheap and small enough to fit into a mobile device, and it'll have OS support.
I really think that's all that is really behind it. The fact that they get to make Samsung look like an also-ran is just icing on the cake; forcing your main competitor to look like the copycat that you've been trying to convince everyone that they are is a fantastic side benefit to a long-term technical strategy.
For me, this also says that if you're looking to keep your phone that you buy THIS year for 3+ years, you're better off with the 5S because the 5C will be locked out all too soon.
The architecture for 64-bit apps on iOS will be almost identical to the architecture for OS X apps
Well, if you read the full quote from the Apple document in question, it says:
That sounds more like "we 64-bitified iOS in a fashion almost identical to the way we 64-bitified OS X", not "64-bit iOS and 64-bit OS X are closer to each other than are 32-bit iOS and 32-bit OS X". You still have to go from Cocoa to Cocoa Touch....
Oh! I know this one!
http://www.youtube.com/watch?v=pO_tXzeiZAQ
Ray Stevens!
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
They're all transistors at the bottom, therefore they're all the same!
I haven't seen any references anywhere about a 64-bit iOS, this sounds much like the amd64 systems being used to run the 32-bit version of Windows. While they will have some advantages with registers for 64-bit arithmetic now, more likely this has been done so when Apple releases a 64-bit version of iOS in 2-3 years they can also update the 5S users.
Actually, I am dismayed at the disastrous lack of quality in the app store, both apps and "apps".
Shareware from 2002 had better quality than 40% of the stuff there! When did mobile devs get the collective meme to be lazy in mobile apps?
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
don't try that open source trickery with me homie, i wasted like five years on debian until i stopped being cheap and bought a mac.
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.
You understand that Android is Linux, and Linux has been on 64 bits since it was ported to the Alpha processor in 1996. Linux has also been on 100,000+ processors for more than 15 years. *That*s why multi-core arm processors are not a problem. FTFY
When did mobile devs get the collective meme to be lazy in mobile apps?
It's the platform vendors that are encouraging it. "Come make apps over here, kids, it's a goldmine! We need tens of thousands more apps by next week to help sell the platform, so get cracking!" A couple of weeks ago, Microsoft put out a tool that was basically a wizard-based UI for generating trivial, pointless "info about my restaurant!" apps. How are customers supposed to find the signal through all the noise when that's how the app store is run?
Breakfast served all day!
ðYs¾ðYðYsZðYs
Adrian Kingsley-Hughes should stick to writing Visual Basic books, not giving his opinions on something he doesn't know. I can advise him to read the first chapters of Mac OS X and iOS internals. Excellent book !
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
So when Apple thinks of bringing the tablets, phones and computers together, it's genius. When Windows did the same, it's the dumbest business decision of the century. Why ..
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
Depends on their market segment. Apple already has the infrastructure in place for shipping fat binaries (sorry, 'universal binaries'). If they can persuade developers to ship x86-64 and ARMv8 fat binaries then a MacBook Air with a quad ARMv8 SoC and a touchscreen (and the ability to run iOS and OS X apps) might be a very interesting device. It would be seriously underpowered in comparison to the MacBook Pro, but the current MacBook Air is anyway.
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.
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?
The processor in the iPhone 5 was designed by Apple. So the question is whether Apple think they can design a better processor than Intel or ARM. And since this is Apple we are talking about, they almost certainly think that they can.
This is not a transition from one third-party processor to another: It is a transition from a third-party processor to a processor that is 100% controlled by Apple.
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...
When you turn six you'll start to care. That will be your first day of obsolescence. From then on each year they'll retire odd bits and pieces from your history. Sort of like a reverse dementia you'll live in the last five years of the present until one day they pull the plug. Forever five.
Already there.
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.
Yeah, just as it was extremely difficult to move apps from RISC Macs to CISC Macs. Oh, wait....
(And that transition involved going from big-endian PPC to little-endian x86; I think iOS runs ARM little-endian.)
The difficulty is not the instruction set architecture, the difficulty is the UI toolkit (Cocoa vs. Cocoa Touch) and the different UI choices made due to screen size and touch-screen-vs-{mouse,touchpad} differences in the hardware.
A lot of people will roll their eyes and talk about how this would supposedly weigh the system down. But it would not have to do so at all. Gnu systems can do this, if you care to set up all the requisite emulators/not-emulators, and dont mind some lack of polish. A modern PC can run all this old software in an emulator without bloating the (by todays standards, extremely modest) requirements of the old software by enough to really notice in most cases. You know why they dont do it?
Because they make money from selling new software. And for decades now they have driven demand for new software by deliberately breaking old software. Just like everyone else in the industry.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Apple has transitioned 32 -> 64 bit and RISC -> CISC already with OS X
Intel chips have been RISC internally for so long that your ignorance isn't even funny.
"Internally" doesn't count from the programmer's point of view; you don't get to write uop code for the particular x86 processor you're running on.
More to the point, the issue with the transition wasn't that it was "RISC to CISC", it that it was "instruction set architecture A to instruction set architecture B". If it were a transition from PowerPC to another RISC instruction set architecture, it would only be easier if the other RISC ISA were big-endian (so that you didn't have to deal with code that's explicitly or implicitly expecting to run on a big-endian ISA).
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.
I need a citation for that statement. While I can readily believe floating point is faster, I'm highly doubtful ARM64 includes 64 general purpose registers. My understanding was the ARM64 general purpose registers are simply twice as large, which is a rather different from doubling their number (even 32 registers tends to almost be a little excessive). In fact I'd read previously they'd optimized the instruction set to include less state, which is a major win for pipelining. ie rather than every instruction including conditional execution, ARM64 has more traditional branches, so it doesn't need to adjust very much if a branch is mispredicted.
The potential implications of 64-bit architecture go far beyond simply more computing power. With 18 billion gigabytes of address space, an iDevice could use iCloud as a giant virtual memory store, just as today's PCs use hard drives or SSDs. That means any bit of data--whether it's a document, a photo, or a chunk of program code--can be addressed by the mobile device as though it's in the device's local memory. If it's not, a "page fault" is generated, causing the data to be automatically fetched from iCloud, and the iPhone goes on like nothing happened. It's a much simpler and faster programming model than dealing with data in files, and I suspect the iCloud "Core Data" facility that is currently giving developers grief is just Apple's first step toward this. Stay tuned. Also, with that much available address space, Apple could dedicate a huge block of iCloud addresses to a massive database shared by all iDevices: things like maps, software updates, regional traffic and weather conditions, sports scores, Siri support, and on and on. (Cross-posted at http://www.macworld.com/article/2048623/how-apple-stretched-its-wings-with-the-iphone-5s-hardware-design.html)
Are you kidding me? And I've got this whole 32-bit to 8-bit migration setup....
I've seen a few apps which have both desktop and mobile versions. I can't name them offhand because I didn't expect this question. I think they were primarily "productivity apps" like spreadsheets, where you can expect to spend a bit of time in. I think the reason it's not more common is iCloud integration. It's not difficult to implement, but does require additional effort in the form of design and most especially testing. I suspect that most developers don't think the effort is worth it. I considered adding it to my app, but when I looked at all the apps I use regularly, none of them include iCloud integration.
I haven't ported my app to OS X, but the base would be easy enough. I'd have to be sure of demand before spending the time and money. I'm sure that's true of any IOS developer of apps that don't require specific hardware.
Plan My Week for iPhone
Regardless of why Apple are going for a 64bit ARM....
Just like the desktop, it will be another 10 years before the software is native 64bit. By that time, who knows, 128-256bit will be here lol
As soon as you allow for 32bit emulation, your basically telling the software developers to stick with it.
Why would any developer want to actively support 2 compiled versions, and, double the support workload?
Even now, on the PC platform, i have "64bit" versions of software that still rely on 32bit applications. The service or driver is 64bit, yet the core applications that runs is still "32bit".
32bit applications will be here forever. No doubt emulated on 128-256bit hardware in the future. Welcome to the future of computing...........
Several journalists have made this mistake, such as the drivel posted here: Trusted Reviews
Please give a stronger warning when you post links like that. Quoting, "Smartphones that use older 32-bit processors can only work with data strings that consist of 32 characters" those details are so badly wrong that is well beyond drivel. I believe the much larger performance gain from ARMv8 is the reduction in context by making only branches conditional. While it loses for tiny bits of conditional code, it means far less state is required in the instruction pipeline. Going from 15 general purpose registers (ARM's program counter takes one of those slots) to 31 general purpose registers allows more code to only use registers, but not all that much.
4GB RAM. Please.
iPhone barely likes giving away 16GB STORAGE. Never mind RAM.
It sets price points on cheap memory. It is going to install expensive memory now?
Likely this is just a strategic next step in technology. The chip is going there anyway, Apple along for ride. Much like 95% of desktops out there that have 64bit cpus and don't utilize I iota of them, neither in size or RAM, special instruction sets, or in programming.
Try to download an iOS 7 app on your older iOS, it'll offer to give you an older version.
The extra registers won't mean that much of a difference as x86. This would be going from 16 to 31 (unless Apple decided to do something different), which you are right probably won't mean much since that probably isn't the performance choke point. But x86 went from 6 to 14, and I remember one game got a 20% speed improvement just recompiling to use the extra registers. Still notice current ARM 32 has more registers than x86-64.
OS X and iOS are much the same. Likely they already have an ARM OS X running (they had x86 running years before the switch). In a few years expect Apple to design a more powerful 4+ core A series chip, and for the latest MacBook Air to be running it, advertised battery life "all day long."
It will translate x86 applications to ARM and cache the translated executable. XCode will have another checkbox for ARM to produce fat binaries native on both platforms. They're using OpenGL on both, so that should translate between the PowerVR and NVidia GPUs.
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.
http://www.anandtech.com/show/7335/the-iphone-5s-review/4
Speedup in Geekbench (just from a re-compile): Integer gain between -25% (Dijkstra, heavy on pointers) and +825% (AES, uses new cryptographic instructions), geometric avarage +37%, median +9%; FP gain between 0% (Mandelbrot) and +195% (DGEMM, uses new DP-SIMD), geometric avarage +36%, median +21%
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.
Funny how about he only ones who keep claiming that are the Fandroids. Tastes more like Hatorade.
Intel chips are RISC as well, the CISC is bolted on top for compatibility reasons.
Errm, the best way to tell if a chip is CISC is to see if it has a microarchitecture inside distractors insist on calling a RISC.