6 ms·

This has been stated before: LLVM Bitcode is architecture specific. It's dependent on the architectures ABI and can contain inline assembly. There are LLVM targ

This has been stated before: LLVM Bitcode is architecture specific. It's dependent on the architectures ABI and can contain inline assembly. There are LLVM targets with corresponding ABIs that are nonspecific to architectures like PNaCL but Apple is not using them Things Apple can do with bitcode: Produce binaries optimized for different ARM processors. Reoptimize with new versions of LLVM as soon as they are available. Use a big database of LLVM IR to tweak optimizations. Keep some optimizations secret and not even publish binaries doing them. The biggest argument IMO that speaks against an Apple ISA is that they would have to rewrite tons of hand tuned assembly code.

geoff-codes 11y ago
> There are LLVM targets with corresponding ABIs that are nonspecific to architectures like PNaCL but Apple is not using them They do indeed support LLVM IR target(s) that are, in fact, much more architecturally-nonspecific than PNaCl, namely the spir[64]-unknown-unknown target. See https://github.com/KhronosGroup/SPIR https://github.com/KhronosGroup/SPIR and /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/openclc (on a Mac, since 10.7). I don't know if bitcode with this target triple is necessarily suitable for the Apple Watch, however.
- bbatha 11y ago
  SPIR is basically portable gpu assembly. I wouldn't count it as an architecturally-nonspecific target.
  - wmobit 11y ago
    It's really not. It's barely an abstraction over LLVM IR
iso8859-1 11y ago
Since all modern CPUs have a ton of microcode, would it be hard to emulate the x86 when needed, and retain backwards compatibility like that?
- geoff-codes 11y ago
  Not particlarly; in fact, apple has basically done this exact thing twice in the past (https://en.wikipedia.org/wiki/Mac_68k_emulator https://en.wikipedia.org/wiki/Mac_68k_emulator), (https://en.wikipedia.org/wiki/Rosetta_(software) https://en.wikipedia.org/wiki/Rosetta_(software). But I believe we're (hypothetically) talking about ARM, not x86, code.
  - rincebrain 11y ago
    The problem with that, at least in the case of Rosetta, is that the QuickTransit technology underlying it got bought by IBM and disappeared from the open market, so doing that trick again would be...a moderate time+cost sink. Wiki for QuickTransit seems to think that a number of prominent people from Transitive hopped to ARM and Apple (which might be telling, given the claims of the original post), but has no citations.
    - monocasa 11y ago
      Eh, JITs aren't the most complicated things on the planet. There's plenty of people who can do it outside of QuickTransit. Like, look inside most emulators.
    - cwp 11y ago
      Given that Apple is writing compilers and designing chips, on-the-fly recompilation shouldn't be a big problem for them.
  - duskwuff 11y ago
    Aside: Apple's 68k-on-PowerPC emulator was an amazing piece of work. It didn't run 68k code in a separate environment; it allowed 68k code to run alongside PowerPC code, to nearly the same level of transparency. Applications could mix ISAs in libraries and code resources, and system extensions could patch PowerPC system functions using 68k code or vice versa. It was surprisingly efficient, too: the first PowerPC systems used system software consisting mostly of 68k code, and still ran faster than the native 68k systems they replaced. I've never seen anything quite like it since. About the closest I've seen is the way that Thumb code can be integrated with native ARM code, and that's explicitly just a different instruction encoding, rather than a separate ISA.
3JPLW 11y ago
Another thing they can do: it allows them to introduce new non-ARM-standard ops and immediately recompile the app store to take advantage of them. Every now and then I see a new comparison of the Swift/ObjC dispatch assembly. Now imagine — that could be a single opcode. Or the dispatch table could get pinned to a particular cache. Or it could be other micro-optimizations that they are in a unique position to exploit with full control of the language, compiler and chip. I have no idea how feasible these things might be or how much of a gain it would create, but they can look through their corpus of LLVM-IR and identify hot-spots where a new opcode would speed everything up by some margin.
- bjackman 11y ago
  Good point, but remember Apple license the ARM architecture from ARM (the company), and they probably aren't allowed to deliberately ship partially-compliant ARM hardware.
  - azinman2 11y ago
    Apple is much bigger than arm and could easily change the rules.
    - gherkin0 11y ago
      They may be smaller, but they have IP Apple needs now. Apple just can't do whatever it wants to just because it's big.
      - azinman2 11y ago
        They could buy arm, or offer enough cash until they capitulate.
saosebastiao 11y ago
From what I understand (which is very little), the RISC-V is very similar to ARM. Could it be possible that Apple is planning a move to RISC-V?
- zerohp 11y ago
  RISC-V is not that close to ARM, and it's not mature enough for Apple to move to it. RISC-V is interesting but I think we'll see it adopted in commercial embedded systems first.

geoff-codes 11y ago

> There are LLVM targets with corresponding ABIs that are nonspecific to architectures like PNaCL but Apple is not using them They do indeed support LLVM IR target(s) that are, in fact, much more architecturally-nonspecific than PNaCl, namely the spir[64]-unknown-unknown target. See https://github.com/KhronosGroup/SPIR https://github.com/KhronosGroup/SPIR and /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/openclc (on a Mac, since 10.7). I don't know if bitcode with this target triple is necessarily suitable for the Apple Watch, however.

bbatha 11y ago
SPIR is basically portable gpu assembly. I wouldn't count it as an architecturally-nonspecific target.
- wmobit 11y ago
  It's really not. It's barely an abstraction over LLVM IR

iso8859-1 11y ago

Since all modern CPUs have a ton of microcode, would it be hard to emulate the x86 when needed, and retain backwards compatibility like that?

geoff-codes 11y ago
Not particlarly; in fact, apple has basically done this exact thing twice in the past (https://en.wikipedia.org/wiki/Mac_68k_emulator https://en.wikipedia.org/wiki/Mac_68k_emulator), (https://en.wikipedia.org/wiki/Rosetta_(software) https://en.wikipedia.org/wiki/Rosetta_(software). But I believe we're (hypothetically) talking about ARM, not x86, code.
- rincebrain 11y ago
  The problem with that, at least in the case of Rosetta, is that the QuickTransit technology underlying it got bought by IBM and disappeared from the open market, so doing that trick again would be...a moderate time+cost sink. Wiki for QuickTransit seems to think that a number of prominent people from Transitive hopped to ARM and Apple (which might be telling, given the claims of the original post), but has no citations.
  - monocasa 11y ago
    Eh, JITs aren't the most complicated things on the planet. There's plenty of people who can do it outside of QuickTransit. Like, look inside most emulators.
  - cwp 11y ago
    Given that Apple is writing compilers and designing chips, on-the-fly recompilation shouldn't be a big problem for them.
- duskwuff 11y ago
  Aside: Apple's 68k-on-PowerPC emulator was an amazing piece of work. It didn't run 68k code in a separate environment; it allowed 68k code to run alongside PowerPC code, to nearly the same level of transparency. Applications could mix ISAs in libraries and code resources, and system extensions could patch PowerPC system functions using 68k code or vice versa. It was surprisingly efficient, too: the first PowerPC systems used system software consisting mostly of 68k code, and still ran faster than the native 68k systems they replaced. I've never seen anything quite like it since. About the closest I've seen is the way that Thumb code can be integrated with native ARM code, and that's explicitly just a different instruction encoding, rather than a separate ISA.

3JPLW 11y ago

Another thing they can do: it allows them to introduce new non-ARM-standard ops and immediately recompile the app store to take advantage of them. Every now and then I see a new comparison of the Swift/ObjC dispatch assembly. Now imagine — that could be a single opcode. Or the dispatch table could get pinned to a particular cache. Or it could be other micro-optimizations that they are in a unique position to exploit with full control of the language, compiler and chip. I have no idea how feasible these things might be or how much of a gain it would create, but they can look through their corpus of LLVM-IR and identify hot-spots where a new opcode would speed everything up by some margin.

bjackman 11y ago
Good point, but remember Apple license the ARM architecture from ARM (the company), and they probably aren't allowed to deliberately ship partially-compliant ARM hardware.
- azinman2 11y ago
  Apple is much bigger than arm and could easily change the rules.
  - gherkin0 11y ago
    They may be smaller, but they have IP Apple needs now. Apple just can't do whatever it wants to just because it's big.
    - azinman2 11y ago
      They could buy arm, or offer enough cash until they capitulate.

saosebastiao 11y ago

From what I understand (which is very little), the RISC-V is very similar to ARM. Could it be possible that Apple is planning a move to RISC-V?

zerohp 11y ago
RISC-V is not that close to ARM, and it's not mature enough for Apple to move to it. RISC-V is interesting but I think we'll see it adopted in commercial embedded systems first.