Apple’s Bitcode Telegraphs Future CPU Plans
1–10 of 101 posts
Re: Apple’s Bitcode Telegraphs Future CPU Plans
#2I thought that just being LLVM bitcode wasn't enough to guarantee portability like the author assumes that it is.
There's ABI specific pieces that are still not abstracted in the bitcode like struct packing rules.
Re: Apple’s Bitcode Telegraphs Future CPU Plans
#3I thought that just being LLVM bitcode wasn't enough to guarantee portability like the author assumes that it is. There's ABI specific pieces that are still not abstracted in the bitcode like struct packing rules.
The ABI would be compatible between similar architectures: Apple has somewhat encouraged developers to provide binaries for all of armv6, armv7, and armv7s in the past, all of which are 32-bit ARM architectures. While some new features might be difficult to take advantage of without high-level information, I imagine a difference as drastic as ARM vs Thumb would be easy to pull off starting from bitcode.
Re: Apple’s Bitcode Telegraphs Future CPU Plans
#4With Bitcode, Apple could change OS X into something like the old TAOS jit based OS. Except for a small kernel, all TAOS executables were intermediate representation files. This IR could be translated to real machine code at the same speed as disk access, and resulted in code running at 80-90% native speed on most platforms.
With software like that, Apple could become independent of any particular software architecture.
(TAOS dates from the 90's and is hard to google, but is mentioned in some papers. And yes, the JIT translator could do that even on 90's machines.)
Re: Apple’s Bitcode Telegraphs Future CPU Plans
#5I thought that just being LLVM bitcode wasn't enough to guarantee portability like the author assumes that it is. There's ABI specific pieces that are still not abstracted in the bitcode like struct packing rules.
Yeah, you more or less can't change struct layout after IR (maybe unless you had a no-aliasing no-FFI guarantee... safe Rust?) But you can encode new or different instructions and add new optimizations.
Re: Apple’s Bitcode Telegraphs Future CPU Plans
#6With Bitcode, Apple could change OS X into something like the old TAOS jit based OS. Except for a small kernel, all TAOS executables were intermediate representation files. This IR could be translated to real machine code at the same speed as disk access, and resulted in code running at 80-90% native speed on most platforms. With software like that, Apple could become independent of any particular software architectu…
Sounds somewhat similar to the IBM AS/400 (renamed many times). Applications were shipped as byte code and translated to the local machine architecture. The translated byte code was appended to the application, a but like NeXT fat binaries or OS-X's universal binaries.
The native byte code was 64bit, though iirc the first implementation used a 32bit address. The result was you could ship an application once and when it came time to move architectures all you had to do is one command to retranslate the byte code.
Very neat. I'm not sure why this approach hasn't been used more often.
EDIT: Looks like they're going exactly the AS/400 route.
Re: Apple’s Bitcode Telegraphs Future CPU Plans
#7I thought that just being LLVM bitcode wasn't enough to guarantee portability like the author assumes that it is. There's ABI specific pieces that are still not abstracted in the bitcode like struct packing rules.
That's correct. Bitcode for a 32 bit processor won't work with 64 bit processors, for instance.
Re: Apple’s Bitcode Telegraphs Future CPU Plans
#8How does dynamic linking work in a scheme like this? Would any pre-compiled libraries need to be distributed as Bitcode as well?
Due to the concerns above, IMO Bitcode is less about compatibility and more about app thinning. It's pretty easy to go from Bitcode to 4 different variants of ARM; but another entirely to go from Bitcode to x86 and ARM. Currently, developers have to ship binaries compiled for multiple architectures, which increases app sizes. I suspect Apple is just building a workflow that creates a device-specific version of each app, and having developers compile to Bitcode simplifies app submission.
Re: Apple’s Bitcode Telegraphs Future CPU Plans
#9With Bitcode, Apple could change OS X into something like the old TAOS jit based OS. Except for a small kernel, all TAOS executables were intermediate representation files. This IR could be translated to real machine code at the same speed as disk access, and resulted in code running at 80-90% native speed on most platforms. With software like that, Apple could become independent of any particular software architectu…
You mean just like Java? The performance overhead of Java versus native code is pretty negligible at this point, and Swift is pretty similar to Java 8. I suspect if Apple wanted to go the intermediate compilation route, they would have just used Java.
I suspect Bitcode is more about helping developers ship a single binary that works across 7 or 8 devices with slightly different ISAs. App thinning is a big push for Apple right now because app sizes are getting out of control with the number of variants that developers are required to compile to. Developers compile to Bitcode, then upload to Apple, who then compiles multiple versions of the machine code, using the App Store to download the correct bundle for the device.
Re: Apple’s Bitcode Telegraphs Future CPU Plans
#10With Bitcode, Apple could change OS X into something like the old TAOS jit based OS. Except for a small kernel, all TAOS executables were intermediate representation files. This IR could be translated to real machine code at the same speed as disk access, and resulted in code running at 80-90% native speed on most platforms. With software like that, Apple could become independent of any particular software architectu…
Sounds somewhat similar to the IBM AS/400 (renamed many times). Applications were shipped as byte code and translated to the local machine architecture. The translated byte code was appended to the application, a but like NeXT fat binaries or OS-X's universal binaries. The native byte code was 64bit, though iirc the first implementation used a 32bit address. The result was you could ship an application once and when…
Actually AS/400 byte code has 128 bit pointers. It was originally implemented on a 48 bit processor (weird 70's architectures FTW!).