12 ms·

Apple’s Bitcode Telegraphs Future CPU Plans

161 points by 127001brewer 11y ago

monocasa 11y ago
I 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.
- saurik 11y ago
  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.
- pshc 11y ago
  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.
- Symmetry 11y ago
  That's correct. Bitcode for a 32 bit processor won't work with 64 bit processors, for instance.
- InertialLemon 11y ago
  Bitcode alone might not be infinitely malleable. But given that Apple knows intimately the original platform the submitted app targeted, it has the ability to add additional logic in iTunes Connect that permits tweaks and assumptions you couldn't get away with in the promiscuous and agnostic setting of a generic compiler toolchain.
- riscy 11y ago
  Not only that, but "[target data layout] is used by the mid-level optimizers to improve code, and this only works if it matches what the ultimate code generator uses. There is no way to generate IR that does not embed this target-specific detail into the IR. If you don’t specify the string, the default specifications will be used to generate a Data Layout and the optimization phases will operate accordingly and introduce target specificity into the IR with respect to these default specifications." Much of this article is simply inaccurate speculation. [1] http://llvm.org/docs/LangRef.html#data-layout http://llvm.org/docs/LangRef.html#data-layout
  - DannyBee 11y ago
    note that data-layout used to be optional, but is now mandatory.
  - deleted 11y ago
    [deleted]
- DannyBee 11y ago
  You are correct, and the article isn't even close to right. There are things you can do if the ABI's are the same, such as optimize for microarches, but they otherwise have literally no idea what they are talking about. Bitcode is meant for repeated optimization of the same IR. That is, it would make sense to start from a well-optimized AOT compiled version of bitcode, then JIT the bitcode at runtime and try to come up with something better once you have profiling feedback. I expect this is the plan, given that it's what everyone else who is serious about LLVM does. It would not make any sense to start from bitcode and try to generate code for different architectures. LLVM is a low level virtual machine for a reason. There has been work on things like virtual ISA's using LLVM (see http://llvm.org/pubs/2003-10-01-LLVA.html http://llvm.org/pubs/2003-10-01-LLVA.html), but the result of this research was, IMHO, that it's not currently a worthwhile endeavor. You also can do things like restrict bitcode in ways that make it portable (like, for example, PNaCL), but this is closer to the LLVA work than anything else (It's essentially a portability layer) It actually still requires porting, just porting to the single portability layer.
  - nickpsecurity 11y ago
    I appreciate the clarification.
- bobajeff 11y ago
  Perhaps someone can explain to me why converting a binary straight from one architecture to another couldnt be done. If emulators can work why not translaters?
  - Someone 11y ago
    An emulator has run-time information, a translator does not. That can be important information. For example, the translator might not figure out where data embedded in the code (for example a jump table) ends, and, consequently, continue translating from a point mid-way into a multi-byte instruction. Translating code that generates code (as done in JIT engines or to speed up image processing kernels) also is a challenge; the best one realistically can do is to translate the existing code as-is and then call the translator at run time to do the translation. If that works, the 'call the translator' step may kill any performance that was won by generating code. Of course, self-modifying code is a challenge, too.
  - ahomescu1 11y ago
    The problem is that perfect disassembly (figuring out where every instruction starts, and if bytes are instructions or data) of an arbitrary program is undecidable. Emulators get around that problem by only disassembling instructions that actually get executed at run-time (and therefore can safely be called "code").
stcredzero 11y ago
With 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.)
- spitfire 11y ago
  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.
  - monocasa 11y ago
    Actually AS/400 byte code has 128 bit pointers. It was originally implemented on a 48 bit processor (weird 70's architectures FTW!).
    - spitfire 11y ago
      I stand corrected. Thanks. AS/400 had some really cool technology built into it.
  - Nelson69 11y ago
    There was the OpenGroup's Architecture Neutral Distribution Format, but I'm not sure if it was ever fully realized. Around the time that was proposed some real serious energy was put in to C compiler optimization, across the industry. It does free them up in the future, they can make bigger hardware changes and just have to supply a bitstream player for the older code. I have a difficult time envisioning the architecture changes that make tons of sense to Apple right now though, other than like swapping video on their ARM chips and stuff like that. Running iOS apps on the desktop might make a ton of sense for some of them or some sort of tweener between the iPad and Mac book.
exelius 11y ago
How 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.
- hundchenkatze 11y ago
  Yeah, according to Apple "If you provide bitcode, all apps and frameworks in the app bundle need to include bitcode." https://developer.apple.com/library/prerelease/ios/documentation/IDEs/Conceptual/AppDistributionGuide/AppThinning/AppThinning.html#//apple_ref/doc/uid/TP40012582-CH35-SW2 https://developer.apple.com/library/prerelease/ios/documenta...
drfuchs 11y ago
I managed to ask Chris Lattner this very question at WWDC (during a moment when he wasn't surrounded by adoring crowds). "So, you're signaling a new CPU architecture?" But, "No; think more along the lines of 'adding a new multiply instruction'. By the time you're in Bitcode, you're already fairly architecture-specific" says he. My hopes for a return to big-endian are dashed. [Quotes are approximate.]
- twoodfin 11y ago
  That sounds about right. No radical architectural shifts, but bitcode submissions should let Apple optimize apps automatically for whatever latest tweaks are available in issue width or fused instructions. My most radical speculation is an iPhone A-series chip with an additional low power ARM core especially to support Watch apps without burning too much "host" device battery.
- kmicklas 11y ago
  Why on earth would you ever want to _return_ to big-endian?
  - Marat_Dukhan 11y ago
    To think different
  - drfuchs 11y ago
    Because big-endian matches how most humans have done it for most of history ("five hundred twenty one" is written "521" or "DXXI", not "125" or "IXXD"). Because the left-most bit in a byte is the high-order bit, so the left-most byte in a word should be the high-order byte. Because ordering two 8-character ascii strings can be done with a single 8-byte integer compare instruction (with the obvious generalizations). Because looking for 0x12345678 in a hex dump (visually or with an automatic tool) isn't a maddening task. Because manipulating 1-bit-per-pixel image data and frame buffers (shifting left and right, particularly) doesn't lead to despair. Because that's how any right-thinking person's brain works. The one place I've seen little-endian actually be a help is that it tends to catch "forgot to malloc strlen PLUS ONE for the terminating NUL byte" bugs that go undetected for much longer on big-endian machines. Making such an error means the NUL gets written just past the end of the malloc, which may be the first byte of the next word in the heap, which (on many implementations of malloc) holds the length of the next item in the heap, which is typically a non-huge integer. Thus, on big-endian machines, you're overwriting a zero (high order byte of a non-huge integer) with a zero, so no harm done, and the bug is masked. On little-endian machines, though, you're very likely clobbering malloc's idea of the size of the next item, and eventually it will notice that its internal data structures have been corrupted and complain. I learned this lesson after we'd been shipping crash-free FrameMaker for years on 68000 and Sparc, and then ported to the short-lived Sun386i.
serve_yay 11y ago
Yeah, and their patent applications telegraph the iMac with the fiber-optic shell that's been just around the corner for 10 years.
Ruud-v-A 11y ago
Microsoft has been doing a similar thing with [.NET Native](https://msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx https://msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx) for a while now, though MSIL is much higher level than LLVM IR. With .NET Native, you _can_ submit your app once an run on ARM and x86, 32-bit or 64-bit.
chuckcode 11y ago
Note that gcc considers their monolithic design a feature to encourage companies to contribute back code rather than a painful lesson to be learned from... http://gcc.gnu.org/ml/gcc/2004-12/msg00888.html http://gcc.gnu.org/ml/gcc/2004-12/msg00888.html https://gcc.gnu.org/ml/gcc/2007-11/msg00460.html https://gcc.gnu.org/ml/gcc/2007-11/msg00460.html
- azakai 11y ago
  The article was talking about the Bitcode design in LLVM, not the plugin situation. Yes, gcc considered making plugins hard a feature, but as for a design that separates the frontend and backend in order to make each more modular, then gcc in fact does have such a thing, gimple, https://gcc.gnu.org/onlinedocs/gccint/GIMPLE.html https://gcc.gnu.org/onlinedocs/gccint/GIMPLE.html I'm far from an expert, but from what I've seen and heard, gimple is pretty good for what it does. In other words, the author of the article is wrong to say that LLVM learned from a painful lesson in this area.
legulere 11y ago
I wonder how Bitcode will play with profile guided optimization. Will you also provide pgo information to apple or will they generate it.
jarjoura 11y ago
My suspicion is that bitcode allows the App Store team to provide Watch/iOS specific binaries for an individual device. Right now the solution is to create fat binaries that eat precious space. The watch being even more constrained can use all the help it can get.
gojomo 11y ago
I wonder if this could also be a way to protect compiler-tech and silicon trade secrets, even after they're widely used in the field? Perhaps only Apple ever compiles the final, deployed versions of apps.
nickpsecurity 11y ago
This is a smart move. It's essentially what the System/38 (later AS/400 & IBM i) did. They had an ISA or microcode layer that all apps were compiled to. Then, that was compiled onto whatever hardware they ran on. When IBM switched to POWER processors, the just modified that low layer to compile to POWER processors. That let them run the old apps without recompilation of their original source. They used this strategy over and over for decades. Always one to keep in mind. Going further, I think a team could get interesting results combining this with design-by-contract, typed assembly, and certified compilation. Much like verification condition generators, the compilation process would keep a set of conditions that should be true regardless of what form the code is in. By the time it gets to the lower level, those conditions & the data types can be used in the final compile to real architecture. It would preserve a context for doing safe/secure optimizations, transforms, and integration without the original source.
- chmaynard 11y ago
  Based on other comments here, it sounds like the LLVM Bitcode representation is more closely tied to a specific architecture than the System/38 intermediate representation was. Same idea, though.
  - nickpsecurity 11y ago
    I agree. That's either an advantage or another opportunity for modern IT to learn from the past. Those old systems were full of so many tricks they're still outclassing modern efforts in some ways haha.
pilif 11y ago
I really hope this bitcode feature isn't going to cause a lot of trouble for app developers. Up until now, the app you built on your machine (and tested on your devices) is the app you submitted and which is running on your customers machines. In the future, when your app crashes on customer's machines and doesn't on yours, how are you going to debug much less explain this to apple and have them fix the issue for you? This is especially scary when you consider the turnaround time of ~2 weeks before your new build becomes available in the app store for you to test.
- DerekL 11y ago
  You can download the newly compiled binaries to your test devices. The App Store won't release it to customers until you say it's okay.
Corrado 11y ago
When I read something like this my mind wanders and I imagine a future MacBook Pro that, instead of a single Intel processor, contains many ARM processors. 10-15 ARM processors acting as one could offer a whole lot of performance when you needed it (use all of them), and a whole lot of energy saving when you didn't (use 1 of them). With the current trend of multi-core CPUs, I see this as the ultimate form of the architecture. Now, whether Apple will do something like this is or not is anyones guess, but its nice to dream of the possibilities. :)
- coldtea 11y ago
  >I imagine a future MacBook Pro that, instead of a single Intel processor, contains many ARM processors. 10-15 ARM processors acting as one could offer a whole lot of performance when you needed it (use all of them), and a whole lot of energy saving when you didn't (use 1 of them). With the current trend of multi-core CPUs, I see this as the ultimate form of the architecture. Doesn't make sense. What's the difference between "10-15 ARM processors" and 4-8-12 Intel based cores? I mean apart from the fact that we aren't going back to multi-processor architectures, since there's no benefit from that compared to cores (latency, etc).

161 points by 127001brewer 11y ago

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

saurik 11y ago
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.
pshc 11y ago
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.
Symmetry 11y ago
That's correct. Bitcode for a 32 bit processor won't work with 64 bit processors, for instance.
InertialLemon 11y ago
Bitcode alone might not be infinitely malleable. But given that Apple knows intimately the original platform the submitted app targeted, it has the ability to add additional logic in iTunes Connect that permits tweaks and assumptions you couldn't get away with in the promiscuous and agnostic setting of a generic compiler toolchain.
riscy 11y ago
Not only that, but "[target data layout] is used by the mid-level optimizers to improve code, and this only works if it matches what the ultimate code generator uses. There is no way to generate IR that does not embed this target-specific detail into the IR. If you don’t specify the string, the default specifications will be used to generate a Data Layout and the optimization phases will operate accordingly and introduce target specificity into the IR with respect to these default specifications." Much of this article is simply inaccurate speculation. [1] http://llvm.org/docs/LangRef.html#data-layout http://llvm.org/docs/LangRef.html#data-layout
- DannyBee 11y ago
  note that data-layout used to be optional, but is now mandatory.
- deleted 11y ago
  [deleted]
DannyBee 11y ago
You are correct, and the article isn't even close to right. There are things you can do if the ABI's are the same, such as optimize for microarches, but they otherwise have literally no idea what they are talking about. Bitcode is meant for repeated optimization of the same IR. That is, it would make sense to start from a well-optimized AOT compiled version of bitcode, then JIT the bitcode at runtime and try to come up with something better once you have profiling feedback. I expect this is the plan, given that it's what everyone else who is serious about LLVM does. It would not make any sense to start from bitcode and try to generate code for different architectures. LLVM is a low level virtual machine for a reason. There has been work on things like virtual ISA's using LLVM (see http://llvm.org/pubs/2003-10-01-LLVA.html http://llvm.org/pubs/2003-10-01-LLVA.html), but the result of this research was, IMHO, that it's not currently a worthwhile endeavor. You also can do things like restrict bitcode in ways that make it portable (like, for example, PNaCL), but this is closer to the LLVA work than anything else (It's essentially a portability layer) It actually still requires porting, just porting to the single portability layer.
- nickpsecurity 11y ago
  I appreciate the clarification.
bobajeff 11y ago
Perhaps someone can explain to me why converting a binary straight from one architecture to another couldnt be done. If emulators can work why not translaters?
- Someone 11y ago
  An emulator has run-time information, a translator does not. That can be important information. For example, the translator might not figure out where data embedded in the code (for example a jump table) ends, and, consequently, continue translating from a point mid-way into a multi-byte instruction. Translating code that generates code (as done in JIT engines or to speed up image processing kernels) also is a challenge; the best one realistically can do is to translate the existing code as-is and then call the translator at run time to do the translation. If that works, the 'call the translator' step may kill any performance that was won by generating code. Of course, self-modifying code is a challenge, too.
- ahomescu1 11y ago
  The problem is that perfect disassembly (figuring out where every instruction starts, and if bytes are instructions or data) of an arbitrary program is undecidable. Emulators get around that problem by only disassembling instructions that actually get executed at run-time (and therefore can safely be called "code").

stcredzero 11y ago

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

spitfire 11y ago
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.
- monocasa 11y ago
  Actually AS/400 byte code has 128 bit pointers. It was originally implemented on a 48 bit processor (weird 70's architectures FTW!).
  - spitfire 11y ago
    I stand corrected. Thanks. AS/400 had some really cool technology built into it.
- Nelson69 11y ago
  There was the OpenGroup's Architecture Neutral Distribution Format, but I'm not sure if it was ever fully realized. Around the time that was proposed some real serious energy was put in to C compiler optimization, across the industry. It does free them up in the future, they can make bigger hardware changes and just have to supply a bitstream player for the older code. I have a difficult time envisioning the architecture changes that make tons of sense to Apple right now though, other than like swapping video on their ARM chips and stuff like that. Running iOS apps on the desktop might make a ton of sense for some of them or some sort of tweener between the iPad and Mac book.

exelius 11y ago

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

hundchenkatze 11y ago
Yeah, according to Apple "If you provide bitcode, all apps and frameworks in the app bundle need to include bitcode." https://developer.apple.com/library/prerelease/ios/documentation/IDEs/Conceptual/AppDistributionGuide/AppThinning/AppThinning.html#//apple_ref/doc/uid/TP40012582-CH35-SW2 https://developer.apple.com/library/prerelease/ios/documenta...

drfuchs 11y ago

I managed to ask Chris Lattner this very question at WWDC (during a moment when he wasn't surrounded by adoring crowds). "So, you're signaling a new CPU architecture?" But, "No; think more along the lines of 'adding a new multiply instruction'. By the time you're in Bitcode, you're already fairly architecture-specific" says he. My hopes for a return to big-endian are dashed. [Quotes are approximate.]

twoodfin 11y ago
That sounds about right. No radical architectural shifts, but bitcode submissions should let Apple optimize apps automatically for whatever latest tweaks are available in issue width or fused instructions. My most radical speculation is an iPhone A-series chip with an additional low power ARM core especially to support Watch apps without burning too much "host" device battery.
kmicklas 11y ago
Why on earth would you ever want to _return_ to big-endian?
- Marat_Dukhan 11y ago
  To think different
- drfuchs 11y ago
  Because big-endian matches how most humans have done it for most of history ("five hundred twenty one" is written "521" or "DXXI", not "125" or "IXXD"). Because the left-most bit in a byte is the high-order bit, so the left-most byte in a word should be the high-order byte. Because ordering two 8-character ascii strings can be done with a single 8-byte integer compare instruction (with the obvious generalizations). Because looking for 0x12345678 in a hex dump (visually or with an automatic tool) isn't a maddening task. Because manipulating 1-bit-per-pixel image data and frame buffers (shifting left and right, particularly) doesn't lead to despair. Because that's how any right-thinking person's brain works. The one place I've seen little-endian actually be a help is that it tends to catch "forgot to malloc strlen PLUS ONE for the terminating NUL byte" bugs that go undetected for much longer on big-endian machines. Making such an error means the NUL gets written just past the end of the malloc, which may be the first byte of the next word in the heap, which (on many implementations of malloc) holds the length of the next item in the heap, which is typically a non-huge integer. Thus, on big-endian machines, you're overwriting a zero (high order byte of a non-huge integer) with a zero, so no harm done, and the bug is masked. On little-endian machines, though, you're very likely clobbering malloc's idea of the size of the next item, and eventually it will notice that its internal data structures have been corrupted and complain. I learned this lesson after we'd been shipping crash-free FrameMaker for years on 68000 and Sparc, and then ported to the short-lived Sun386i.

serve_yay 11y ago

Yeah, and their patent applications telegraph the iMac with the fiber-optic shell that's been just around the corner for 10 years.

Ruud-v-A 11y ago

Microsoft has been doing a similar thing with [.NET Native](https://msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx https://msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx) for a while now, though MSIL is much higher level than LLVM IR. With .NET Native, you _can_ submit your app once an run on ARM and x86, 32-bit or 64-bit.

chuckcode 11y ago

Note that gcc considers their monolithic design a feature to encourage companies to contribute back code rather than a painful lesson to be learned from... http://gcc.gnu.org/ml/gcc/2004-12/msg00888.html http://gcc.gnu.org/ml/gcc/2004-12/msg00888.html https://gcc.gnu.org/ml/gcc/2007-11/msg00460.html https://gcc.gnu.org/ml/gcc/2007-11/msg00460.html

azakai 11y ago
The article was talking about the Bitcode design in LLVM, not the plugin situation. Yes, gcc considered making plugins hard a feature, but as for a design that separates the frontend and backend in order to make each more modular, then gcc in fact does have such a thing, gimple, https://gcc.gnu.org/onlinedocs/gccint/GIMPLE.html https://gcc.gnu.org/onlinedocs/gccint/GIMPLE.html I'm far from an expert, but from what I've seen and heard, gimple is pretty good for what it does. In other words, the author of the article is wrong to say that LLVM learned from a painful lesson in this area.

legulere 11y ago

I wonder how Bitcode will play with profile guided optimization. Will you also provide pgo information to apple or will they generate it.

jarjoura 11y ago

My suspicion is that bitcode allows the App Store team to provide Watch/iOS specific binaries for an individual device. Right now the solution is to create fat binaries that eat precious space. The watch being even more constrained can use all the help it can get.

gojomo 11y ago

I wonder if this could also be a way to protect compiler-tech and silicon trade secrets, even after they're widely used in the field? Perhaps only Apple ever compiles the final, deployed versions of apps.

nickpsecurity 11y ago

This is a smart move. It's essentially what the System/38 (later AS/400 & IBM i) did. They had an ISA or microcode layer that all apps were compiled to. Then, that was compiled onto whatever hardware they ran on. When IBM switched to POWER processors, the just modified that low layer to compile to POWER processors. That let them run the old apps without recompilation of their original source. They used this strategy over and over for decades. Always one to keep in mind. Going further, I think a team could get interesting results combining this with design-by-contract, typed assembly, and certified compilation. Much like verification condition generators, the compilation process would keep a set of conditions that should be true regardless of what form the code is in. By the time it gets to the lower level, those conditions & the data types can be used in the final compile to real architecture. It would preserve a context for doing safe/secure optimizations, transforms, and integration without the original source.

chmaynard 11y ago
Based on other comments here, it sounds like the LLVM Bitcode representation is more closely tied to a specific architecture than the System/38 intermediate representation was. Same idea, though.
- nickpsecurity 11y ago
  I agree. That's either an advantage or another opportunity for modern IT to learn from the past. Those old systems were full of so many tricks they're still outclassing modern efforts in some ways haha.

pilif 11y ago

I really hope this bitcode feature isn't going to cause a lot of trouble for app developers. Up until now, the app you built on your machine (and tested on your devices) is the app you submitted and which is running on your customers machines. In the future, when your app crashes on customer's machines and doesn't on yours, how are you going to debug much less explain this to apple and have them fix the issue for you? This is especially scary when you consider the turnaround time of ~2 weeks before your new build becomes available in the app store for you to test.

DerekL 11y ago
You can download the newly compiled binaries to your test devices. The App Store won't release it to customers until you say it's okay.

Corrado 11y ago

When I read something like this my mind wanders and I imagine a future MacBook Pro that, instead of a single Intel processor, contains many ARM processors. 10-15 ARM processors acting as one could offer a whole lot of performance when you needed it (use all of them), and a whole lot of energy saving when you didn't (use 1 of them). With the current trend of multi-core CPUs, I see this as the ultimate form of the architecture. Now, whether Apple will do something like this is or not is anyones guess, but its nice to dream of the possibilities. :)

coldtea 11y ago
>I imagine a future MacBook Pro that, instead of a single Intel processor, contains many ARM processors. 10-15 ARM processors acting as one could offer a whole lot of performance when you needed it (use all of them), and a whole lot of energy saving when you didn't (use 1 of them). With the current trend of multi-core CPUs, I see this as the ultimate form of the architecture. Doesn't make sense. What's the difference between "10-15 ARM processors" and 4-8-12 Intel based cores? I mean apart from the fact that we aren't going back to multi-processor architectures, since there's no benefit from that compared to cores (latency, etc).