9 ms·
Bitcode (iOS, watchOS)
- ubercow 11y agoSo is this just LLVM IR?
- nekitamo 11y agoYep. I hope they leave this optional for iOS, as we use some proprietary libraries which we don't think the vendor will ship a new version of :(
- pgeorgi 11y agoYou may get by with a decompiler as laid out in http://llvm.org/devmtg/2013-04/bougacha-slides.pdf http://llvm.org/devmtg/2013-04/bougacha-slides.pdf And since you'll certainly not be the only one with that problem, Apple making it mandatory for iOS would probably spur development in that area.
- ponytech 11y agoI am not so confident : they now require that you ship a 64 bits version of your apps, which can be also be a problem if you use 32 bits only proprietary libraries.
- coob 11y agoThere's a good reason for that requirement. Loading 32bit apps on a 64but device requires loading all the 32bit version of shared libs, massively increasing the memory footprint.
- johntb86 11y agoI'm curious how that works. LLVM bitcode backwards/forwards compatibility is quite poor, from what I've heard. Will they fix some bitcode version to transmit, and have translators on the client/server sides? Have a bunch of different toolchain versions on the server side? Force everyone to resubmit with a newer version if they want to do any changes on the server side?
- joosters 11y agoPresumably the backwards/forwards compatibility is poor simply because people don't tend to have these files sitting around, they mostly exist (at the moment) as part of a compilation framework and are tempfiles. If needed, it wouldn't be too for someone with a few programmers (Apple could spare a few!) to write the proper versioning to upgrade/downgrade the file format as LLVM changes?
- deleted 11y ago[deleted]
- freewizard 11y agoIf to put Swift on Linux and Bitcode together, I'd take a wild guess that an apple powered PaaS is on its way.
- tomwilson 11y agoThey kind of have that already with CloudKit - it's not suitable for all use cases though.
- Osmium 11y agoThey've just announced a major new addition to CloudKit though to basically allow integration into CloudKit via web apps, which seems like a pretty big deal.
- freewizard 11y agoCloudKit is BaaS (like Parse), and here I meant PaaS (like AppEngine).
- TazeTSchnitzel 11y agoSwift on Linux is probably just a consequence of Apple using Linux on their servers. Don't read too much into it.
- freewizard 11y agoPats (like AppEngine) is exactly the things can happen on server.
- TD-Linux 11y agoSo, is there any actual documentation of this anywhere?
- Someone 11y agohttp://llvm.org/docs/BitCodeFormat.html http://llvm.org/docs/BitCodeFormat.html
- pjmlp 11y agoInteresting to see Apple is following Microsoft (MDIL, .NET Native) footsteps.
- coldtea 11y agoIs there any substantial new technology a major company gets that another competing company wont try to match sooon?
- pjmlp 11y agoYeah, but the funny thing is how Apple's AOT compilation toolchain was being discussed by some Apple fans as the way to go. Now they turn around and follow what the others are doing.
- gok 11y agoBoth .NET Native and this (bitcode) are an AOT compilation toolchain.
- pjmlp 11y agoWho says otherwise? What I said is that I heard from many Apple fans that it didn't make sense the MDIL/.NET Native compilation model[0] and directly compilation from XCode to the device was the way to go. [0]Uploading IL to the store and having a server based compiler generate native code before download.
- coldtea 11y agoIt still is AOT. There's just an intermediary step, which is what you send to Apple, but the code is compiled in its servers, not in the runtime. It's not like LLVM doesn't have several steps already in its pipelines.
- pjmlp 11y agoI guess you don't know how MDIL and .NET Native work.
- arcticbull 11y agoIn case y'all are curious it would make sense if this is LLVM bitcode: http://llvm.org/docs/BitCodeFormat.html http://llvm.org/docs/BitCodeFormat.html Seems like a very smart way to keep things binaries up to date without developer intervention -- and possibly even allow re-targeting to different CPU architectures after the fact. That would eliminate the need for something like Rosetta if Apple ends up switching major CPU architectures again some day. I really think that LLVM is one of the best things to happen to computer science in a long, long time.
- svnssn 11y agoI'm quite sure it is LLVM bitcode. Btw, the creator of LLVM is the same guy who created Swift, i.e. Chris Lattner.
- hamstergene 11y agoI remember a letter from some time ago saying that LLVM IR format is private to specific version of LLVM, and is not guaranteed to be compatible with other versions in the future or in the past. Does this announcement mean that is not the case anymore, and LLVM IR is backwards compatible now?
- microtherion 11y agoGiven that Apple controls that format, even if it were to continue to change in the future, that would not necessarily be an unsurmountable obstacle.
- delinka 11y agoAll of LLVM is open source, and the format isn't quite so fluid as GP makes it sound. It should be relatively trivial for one versed in the LLVM codebase to grok the current features of the bitcode. That said, as long as you keep an indication of the LLVM version that your bitcode was generated with, I really don't see a problem with fluid bitcode specs.
- legulere 11y ago
- advanderveer 11y agoI find it interesting this hasn't gotten as much attention as other announcements. It seems to hand over a great deal of responsibility to Apple, at least in terms of performance. Something some might feel comfortable with or not. I can imagine this lack of control about what instructions will actually run on the hardware might not fair well with some developers?
- pjmlp 11y agoMost likely, however this is already being done in the other mobile platforms.
- nly 11y agoNot really, you can ship native code on Android and, for Java apps, intermediate bytecode is delivered to end-user phones, not compiled in the cloud.
- pjmlp 11y agoWindows Phone 8: http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-and-Peter-Sollich-Inside-Compiler-in-the-Cloud-and-MDIL http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-and... Windows Phone 10: http://channel9.msdn.com/Shows/Going+Deep/Inside-NET-Native http://channel9.msdn.com/Shows/Going+Deep/Inside-NET-Native As for Android, having ART on the phone is technicality, given the platform fragmentation Google rather leaves to the OEMs the task of making ART generating the proper code.
- cpr 11y agoAs long as you have (and keep updating to) the devices in question to test on, you'll have full performance info.
- m_mueller 11y agoI'm thinking that Apple sees a new threat to their mobile (profit) dominance: Fully portable Mobile+Desktop OS enabled through Core M, i.e. Windows 10. "Bitcode" is them preparing to unify their OSes just in case Win10 is successful and buyers suddenly want to have one device to rule them all (i.e. MS Continuum). This could very soon be a reality - and Apple seems to be preparing themselves. Smart move [1]. [1] http://img2.wikia.nocookie.net/__cb20130701185217/jurassicpark/images/e/e3/JP1_VelociraptorCurtain.jpg http://img2.wikia.nocookie.net/__cb20130701185217/jurassicpa...
- Sanddancer 11y agoMy thought is more that they are going the Android route of using an intermediary bytecode, to get both platform independence, but on-device compilation for performance. If they can push hardware that will automatically run faster, that makes it all that much easier to sell new product.
- m_mueller 11y agoYes, I didn't mean Apple is going the MS route from a technical point of view, just the timing of their platform independence efforts leads me to believe that it has to do with pressure (or the potential thereof) by Microsoft.
- th0br0 11y agoI'm honestly surprised that noone has commented on the security implications of this, yet. After all, allowing Apple to recompile your "bitcode" essentially means, that the user can in no way validate that the version he's running is the version the developer published. It would be fairly straightforward to perform MITM attacks on apps this way. (And, sure, Android's APKs are faced with quite the same issue - but AFAIK Google doesn't modify your bytecode (yet?))
- 0x0 11y agoThey could already do that. They sign and encrypt the (plaintext) code segment you submit so they could easily insert a JMP to their own payload at the head of your code any time
- chc 11y agoThey could also just have the kernel do whatever it wants to your program, because they control that too. If you are worried that Apple might tamper with your binaries if given the chance, using an iOS device is pure folly, because they outright control much more important parts of your system (the kernel, the UI libraries, the RNG…).
- vbezhenar 11y agoWhy do they encrypt code segment? Signature is essential, of course, but encrypting looks unnecessary.
- 0x0 11y agoIt's their fairplay DRM implementation that is supposed to prevent piracy.
- deleted 11y ago[deleted]
- omarforgotpwd 11y agoApple has a pretty complex boot system in which each stage of the boot process verifies a checksum of the next layer before starting it up. The lowest layer is etched in ROM. Theoretically, if you verify the integrity of the bitcode, and you verify the integry of the bitcode compiler, you should be able to trust the native binary as well.
- fra 11y agoThis is going to spell the end of all 3rd party crash reporting tools.
- jrazavian 11y agoI'm not sure I understand what you are implying. How so?
- chedabob 11y agoPossible issues with symbolicating the crash logs if you don't have the debug symbols as they're generated on Apple's side.
- fra 11y agoIf Apple does the linking of the final binary for you, you won't have a way to recover the symbols <-> address mappings you need to desymbolicate (that'd the dSym file you usually upload to hockeyapp)
- unsigner 11y agoThey seem to be preparing for something in the 2-5 years timeframe, but what? Least grandiose theory I can come with: two ARM cores in the Watch, one big, one small, with different instruction sets, for active/standby modes.
- robmcm 11y agoI'm guessing they can just optimize for the watch when they come up with a new trick. It also means they can optimize for different devices.
- jkestner 11y agoThey're preparing for anything. Apple has a dislike for relying heavily on any partner in their DNA, thanks to PowerPC.
- glhaynes 11y agoI think this is exactly it. Perhaps they do have a specific usage in mind that they're aiming for, but I bet they'd be taking these same steps regardless.
- TazeTSchnitzel 11y agoNot just that. Apple also switched from 68k to PowerPC.
- jkestner 11y agoTrue, though nominally the same partner. Motorola was the M in AIM, though yes, IBM did the heavy lifting. (Remember Motorola made a Mac clone? How weird.) And the situation wasn't as dire then.
- CrLf 11y agoSo Apple is following following the footsteps of IBM, huh? http://en.wikipedia.org/wiki/IBM_System_i#Instruction_set http://en.wikipedia.org/wiki/IBM_System_i#Instruction_set
- pjmlp 11y agoEveryone is. I got to understand better the whole concept of having a bytecode format for executables, with JIT/AOT deployment options when I started delving into the old mainframe world. I used to do AS/400 backups, but never coded for it. So it was quite interesting to discover the all TIMI concepts. Also other similar environments like the Burroughs B5000. The old is new again. :)
- sudioStudio64 11y agoThat's true...MS has been doing this for phone and windows store apps (the few that there are) that are written in .Net to improve performance. The get AOT'd from CIL to target binary when uploaded to the store. I wonder why this isn't bigger in the FOSS world...maybe because the source and toolchain are already available...I don't know, it might be a neat idea to have an IR userland that compiles on install.
- sudioStudio64 11y agoThat's really cool. I like that idea in general. The other day I was reading about OS/400 on wikipedia. It always used an intermediate bytecode...and because of it they were able to seamlessly (who know how seamlessly) from architecture to architecture.
- js2 11y agoThis will affect crash reporting and symbolication. Presumably Apple strips debug symbols when they compile. Will they make the dsyms (DWARF containing files for stripped mach-o binaries, necessary to symbolicate crash reports) available somehow? If not, third parties (or anyone who chooses to handle their own crash reports directly) are in trouble.
- goatforce5 11y agoJohn Siracusa tweeted a rumor yesterday speculating/hinting at ARM Macs. https://twitter.com/siracusa/status/608029277963972608 https://twitter.com/siracusa/status/608029277963972608 How fast are the fastest ARM chips compared to the lower-end Intel chips? Could we see low-powered Mac Airs with long battery lives?
- mirekrusin 11y agoDoesn't it open doors for proprietary LLVM optimisations hidden from others?