Slashdot Mirror
Apple Watch Apps Instantly Went 64-Bit Thanks To Obscure Bitcode Option (venturebeat.com)
Jeremy Horwitz, writing for VentureBeat: An obscure feature in Apple's Xcode development software enabled Apple Watch apps to make an instant transition from 32-bit to 64-bit last month, an unheralded win for Apple Watch developers inside and outside the company. The "Enable Bitcode" feature was introduced to developers three years ago, but the Accidental Tech Podcast suggests that it was quietly responsible for the smooth launch of software for the Apple Watch Series 4 last month.
Support for Bitcode was originally added to Xcode 7 in November 2015, subsequently becoming optional for iOS apps but mandatory for watchOS and tvOS apps. Bitcode is an "intermediate representation" halfway between human-written app code and machine code. Rather than the developer sending a completely compiled app to the App Store, enabling Bitcode provides Apple with a partially compiled app that it can then finish compiling for whatever processors it wants to support. The report suggests that this change allowed Apple to avoid the great "appocalypse" which occurred when it decided to kill support for 32-bit apps on iOS.
Support for Bitcode was originally added to Xcode 7 in November 2015, subsequently becoming optional for iOS apps but mandatory for watchOS and tvOS apps. Bitcode is an "intermediate representation" halfway between human-written app code and machine code. Rather than the developer sending a completely compiled app to the App Store, enabling Bitcode provides Apple with a partially compiled app that it can then finish compiling for whatever processors it wants to support. The report suggests that this change allowed Apple to avoid the great "appocalypse" which occurred when it decided to kill support for 32-bit apps on iOS.
Did Apple Watches suddenly gain some dire need for 64-bit address space?
it was mandatory on the platform for THREE FUCKING YEARS. hardly 'obscure'.
So other than addressing >4Gb of memory, what are the upsides?
Only the State obtains its revenue by coercion. - Murray Rothbard
The Pascal-P system did it with "p-code" back in the 1970's ...
And Open Software Foundation's ANDF system for Unix programs written in C back in the early '90s.
The "bitcode" is not an Apple invention, but is a file encoding for LLVM-IR, the intermediate representation of programs used internally by the LLVM/clang compiler. ... but Apple's App Store is not really a distributed system either but a funnel through which all "watchOS" apps have to go, so Apple can probably manage it.
LLVM-IR is very much not suitable for program distribution
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
LLVM bitcode contains (and needs) the datalayout of the target. This datalayout means such things as default data sizes and alignment rules. Pointer size is different for 32- and 64-bit architectures, so same LLVM bitcode cannot work in both 32- and 64-bit mode.
So, bitcode alone cannot explain portability to 64-bit.
It might be that the development tools have compiled separate bitcode files for 32-and 64-bit architectures.
So other than addressing >4Gb of memory, what are the upsides?
64-bit ARM processors have more than double the number of general purpose registers than 32 bit ARM processors have. This can speed up code considerably, by reducing the number of load/store instructions needed when you have half the registers. And as decisions as to register use is done at compile time (and not at runtime), this benefits 64-bit code mores than 32-bit code (as the compiler has to presume the lowest common denominator, and all compile 32-bit code assuming the 15 general purpose registers found on 32-bit ARM CPUs).
The big upside for Apple of course is no longer needing to maintain or ship any legacy 32-bit codebases. All current Apple devices now feature a 64-bit CPU, so Apple can get rid of 32-bit kernel support. If all apps are required to be 64-bit, Apple doesn't need to maintain or ship 32-bit system libraries. Xcode will be simplified, as there won't the any need for 32-bit build tools or targets.
Not having to maintain the massive amount of 32-bit support code inside Apple's various OS's will be a big win for Apple -- but that win will also trickle down to end-users, as Apple will be able to put more effort and emphasis on common codebases for their entire product line, and can put development resources that were being used to maintain 32-bit support to other tasks.
Yaz
.... except the compiling happens in the app store infrastructure, not on the watch. So nothing like Java's byte code and JIT compilation. Not even like Android and it's ART runtime, that compiles the code when it's installed.
Or IRIX. I had my first 64-bit desktop machine around 1996 (SGI Indigo).
No sig today...
64bit ARM architectures are more power efficient than the older 32bit ones. ARMv8 is a more advanced instruction set than ARMv7.
Better instruction set
larger registers
more registers
Yep. 32-bit languages totally can't have a 64 bit data type.
(or double precision math - not a lot of people know that 32-bit apps are limited to single precision!)
No sig today...
Yeah, nothing like it. Compiling on a computer that sits on your desk is totally different than compiling on a computer that sits in your pocket or on a computer that straps to your arm. Even if those computers are architecturally similar if not identical. The key take away here is the shape and location of your compute is vitally important to this definition of what makes Java and JIT distinctive.
“Common sense is not so common.” — Voltaire
Not having to maintain the massive amount of 32-bit support code inside Apple's various OS's will be a big win for Apple
So will we all just abandon to the scrap heap all the very expensive Apple devices that already exist and are still working? You know, all the 32 bit devices?
If Apple is not supporting 32 bit OSs anymore, then are app developers going to have to keep a copy of XCode 7 or whatever that does support the vast number of legacy devices?
So it's a bit like UCSD P-code?
https://en.wikipedia.org/wiki/...
No sig today...
Yeah, having to use two CPU registers to hold my file offsets was a real chore. It was impossible for 20 year old Unix systems to add system calls to with names like lseek64(). We can only write software that is as simple as possible, and we would never include even slightly complicated interfaces to do something as basic as accessing large files.
Also 32-bit systems never offer 64-bit values for time stamps, so those will all explode in the year 2038. You don't want your obsolete 32-bit watch to EXPLODE do you?
(actual upsides are related to the industry providing security updates and enhancements to newer architectures)
“Common sense is not so common.” — Voltaire
You pay for additional registers with increased context switch latency. It's not really a slam dunk. Some architectures only make you pay on a context switch for registers you used, but if you're not using them then you probably didn't need them, so assumed an efficient program uses all the registers.
Having lots of registers and good swizzle operations can help SIMD (single instruction, multiple dispatch). But that doesn't come out of the general purpose register set on most architectures.
Your CPU architecture isn't the biggest factor when it comes to general purpose computing. A bad one will hinder you, but there are several good enough ones. Having fewer state changes can improve your thermodynamic efficiency (so less bits, less registers, narrower "way" cache), but other factors like manufacturing technology tend to matter more. Use case matters the most by far.
Apple's hardware team is able to leverage testing and validation for a single CPU architecture is a savings for them (I'm on a SW validation team for an SoC vendor, so I have some idea of the amount of work involved). Apple's volumes as a chip producer are perhaps low enough for this to matter significantly. I highly suspect this choice makes as much sense for bean counters than it does for technical reasons.
“Common sense is not so common.” — Voltaire
So will we all just abandon to the scrap heap all the very expensive Apple devices that already exist and are still working? You know, all the 32 bit devices?
All of the old software and development tools still work if you need to target a really old device.
Apple has been primarily 64-bit for a very long time now. 64 bit support for OS X came out in 2005, all new Macs had 64-bit hardware by 2007, and in 2011 64 bit became required with Mac OS X Lion (10.7). The iPhone has been 64 bit since the iPhone 5s (2013). AppleTV has been fully 64-bit for two generations now (since 2015), however it needs to be noted here that prior to the 2015 model, the AppleTV didn't permit 3rd party apps anyway.
And as this article indicates, bitness of the tvOS and Apple Watch devices matters less, as Apple accepts the applications as byte code from the vendors, and can compile it on the fly for specific devices in whatever bitness they support. As such, your device has to be quite old to need 32 bit support, and Apple for at least the last year has required all apps submitted to its app stores to be 64-bit.
If Apple is not supporting 32 bit OSs anymore, then are app developers going to have to keep a copy of XCode 7 or whatever that does support the vast number of legacy devices?
The number isn't as vast as you are implying. Unsupported Macs would have to be at least 12 years old now. Unsupported iOS devices are more than 5 years old at this point. The AppleTV has never had a revision that permitted 3rd party apps which wasn't 64 bit. It's only on the Apple Watch where there is a currently supported 32 bit OS -- and as the article indicates, Apple got around much of the issues between 32-bit and 64-bit versions by having byte code based apps which it can compile to the necessary architecture on the fly on your behalf.
So yes -- if you for some reason really have to target old 32 bit devices, at some point you'll need an older Xcode around. Presumably you're deploying these to the devices yourself, as the App Store hasn't permitted 32-bit apps for at least the last year. Next year macOS is dropping 32-bit application support altogether.
Yaz
Yeah, nothing like it. Compiling on a computer that sits on your desk is totally different than compiling on a computer that sits in your pocket or on a computer that straps to your arm. Even if those computers are architecturally similar if not identical. The key take away here is the shape and location of your compute is vitally important to this definition of what makes Java and JIT distinctive.
Hey dumbass.
The compilation is done on Apple's SERVERS, before the App is downloaded to your device.
No, he surely didn't, and it was no where near as fast or powerful as the watch. But, that doesn't matter. The interesting thing has nothing to do with the Apple Watch 4 being a 64bit wide architecture.
The interesting thing in this story (for all the non-programmers out there), is the IDE handling natively the cross-compilation difficulties of moving between 32 and 64 bits. That means it is allocating memory and changing data types of objects at compile-time.
Pretty cool stuff.
Frankly it is ridiculous that this sort of thing is even a problem. Apple, Google, Microsoft, etc should all be offering the ability to translate or run all 8-bit, 16-bit, 32-bit and 64-bit software on the newer OSs and hardware. It is an easy problem. They should also be offering emulation or JITC (Just In Time Compilation) or FRTC (First Run Time Compilation) for all older software to run on the newer hardware and OSs.
You pay for additional registers with increased context switch latency. It's not really a slam dunk.
Agreed -- the potential for performance increases isn't linear, and isn't guaranteed for all possible workloads. But so long as the increase in context switch latency is less than a non-trivial programs full load/store set, you'll still see performance improvements.
I highly suspect this choice makes as much sense for bean counters than it does for technical reasons.
I suspect the bean counters see the biggest benefit from the software side, with no longer having to maintain parallel 32-bit and 64-bit codebases and/or build apparatus. An Apple developer fixing a bug in a system library currently needs to a) potentially write two different fixes (moreso for drivers, the kernel, and low-level libraries), b) build for both 32-bit and 64-bit (probably as an automated step), and c) test in both. And for a new feature, they may have to additionally write/build/run two sets of unit and/or integration tests. QA testing needs to be done for both 32-bit and-64 bit. It's roughly twice the work for the development and QA teams, and cleaving that in half is a massive win for Apple.
Keeping around old stuff just for the sake of keeping around old stuff builds up technical debt, and I can see Apple wanting to go 64-bit-only across their entire product line as a way to rid themselves of some of that debt, and free up resources for other tasks.
Yaz
Sure it was clumsy and inconvenient, but boy did I look cool!
64-bit ARM processors have more than double the number of general purpose registers than 32 bit ARM processors have.
More transistors, more power suck. On a device that doesn't need the extra performance, it would benefit much more from extra battery life.
Spin, spin, spin. Admit it, the only useful purpose of 64 bits CPU on a watch is a bigger number.
When all you have is a hammer, every problem starts to look like a thumb.
Spin, spin, spin. Admit it, the only useful purpose of 64 bits CPU on a watch is a bigger number.
As an end-user there may be no obvious benefit to you, but as I've mentioned it's of benefit to Apple, especially on the software development side.
watchOS shares code with iOS, tvOS, and macOS. There are big benefits for Apple by being able to keep all of these 64-bit from top to bottom; it makes little sense for Apple to keep developing 32 bit development, build tooling, and kernel and library code just for watchOS, when all of their other platforms are 64-bit.
Yaz
More transistors means more power, all things being equal.
However, if you finish your job faster you can sleep faster, which probably uses less power overall. Thats the basic power philosophy of iOS. You can't just look at one thing and say it's more expensive; it's how it impacts the overall system's performance that matters. That's one difference in how Apple does things, or at least how they used to do things.
SIMD (single instruction, multiple dispatch^H^H^H^H^H^H^H^Hdata).
FTFY.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Some of the mainframes where rocking 64 not address spaces well back to the early 80s and possibly earlier. Million dollar machines though.
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
And if that was the only thing that the watch had to do, that observation would be relevant.
But it is not.
A server is a computer sitting in a rack instead of on a desk.
Support my political activism on Patreon.
Everyone else is having charging issues, signal strength issues, antenna issues, front facing camera issues.
What a piece of shit apple produced
First off, "signal strength issues" and "antenna issues" are inextricably linked; so thanks for trying to get two bites at the same apple (see what I did there?).
If by "Front-Facing Camera Issues" you are talking about the difference in the smoothing algorithms in the iPhone Xs, that is simply a misunderstanding of how it works:
https://www.macrumors.com/2018...
As for the Charging Issues, the Jury is still "out" on that one...
A server is a computer sitting in a rack instead of on a desk.
Really? I never would have known that, thanks!
Idiot.
Isn't the point the battery powered device doesn't need to compile any code? That takes power.
Next year macOS is dropping 32-bit application support altogether.
Will Wine then have to become actually an emulator?
Will Wine then have to become actually an emulator?
I suspect you'll have to run it in a VM. 64-bit WINE exists, however there is a major incompatibility with 64-bit macOS that causes issues, where the only workaround appears to be using emulation.
Yaz