6 ms·

This is great for x86, but for low-overhead multi-platform binaries, IBM came up with a pretty good solution decades ago with OS/400 TIMI (Technology Independen

by KMag 5y ago

This is great for x86, but for low-overhead multi-platform binaries, IBM came up with a pretty good solution decades ago with OS/400 TIMI (Technology Independent Machine Interface), which is basically Android Runtime's install-time native code generation, but suitable as a C/RPG/COBOL/CL compilation target and not mandating a garbage collector. Given Apple has undergone 3 CPU architecture migrations by now and employs Chris Latner, I was hoping they'd move to something vaguely like a modernized version of TIMI (maybe based on LLVM bitcode) as the default XCode target for Apple Silicon. Rosetta has been good enough so far, but I can see a future where Apple starts really specializing cores (say ultra-low power cores for watches and glasses or an extreme form of big.LITTLE) to the point where it makes sense for them to have radically new instruction encodings.

snovv_crash 5y ago
iOS already supports bitcode deployments to the app store, I believe this is the direction they are taking to solve this problem.
- KMag 5y ago
  Very nice. I hope that in the future, native code will be the distribution format about as often as we write inline assembly. Sometimes you'll really need precise control over instructions, but for 99% of code, it's not worth the cost in giving up long-term technology improvements. In particular, x86's total store ordering memory model causes some memory fences to disappear at the machine code level. The Aarch64 relaxed memory model allows for lower cache synchronization overhead, but code with correct memory fences compiled to x86 loses this information, requiring overly conservative binary translation/higher overhead TSO mode in Aarch64 binary translators. These days, hardware acquire/release/full flavors of memory fences better match the C++ and Java memory models, but some hardware has load/store/full flavors of memory fences. Binary translation across these flavors means changing all fences to full fences, or else some static analysis that's far beyond anything I'm aware existing at this time.
  - saagarjha 5y ago
    Or just specialized hardware to do the TSO…
    - KMag 5y ago
      One could, but then one would give up the advantages of a relaxed memory model.
- masklinn 5y ago
  Afaik bitcode remains architecture-dependent, so bitcode deployments is mostly do they can re-optimise, and a convenient component of app slicing (if they end up generating the final bundle anyway, having more visibility into what’s what is useful).
  - KMag 5y ago
    I think re-targeting bitcode for a different architecture with the same pointer size and endinness is a pretty light weight operation, but I might be wrong. I'm pretty sure it's orders of magnitude lower overhead and less complicated than dynamically recompiling native code.
    - masklinn 5y ago
      Oh for sure.
  - qznc 5y ago
    With C/C++ the preprocessor makes architecture-dependent decisions. Bitcode has no chance to fix that.
    - Spivak 5y ago
      So this is true but also not that relevant, bitcode is your architecture.
why_only_15 5y ago
Apple hasn't employed Chris Lattner since January 2017: http://nondot.org/~sabre/Resume.html http://nondot.org/~sabre/Resume.html
skissane 5y ago
> This is great for x86, but for low-overhead multi-platform binaries, IBM came up with a pretty good solution decades ago with OS/400 TIMI (Technology Independent Machine Interface), which is basically Android Runtime's install-time native code generation, but suitable as a C/RPG/COBOL/CL compilation target and not mandating a garbage collector. To be honest, I think the dream of portability which TIMI represented is mostly dead in recent IBM i versions. More and more functionality depends on the AIX compatibility environment, PASE, which doesn't run under TIMI, it is full of standard AIX XCOFF binaries containing POWER machine code. (Interspersed with calls to IBM i-specific APIs which allow PASE binaries to access services provided by code running inside and underneath TIMI.) Given the increasing use of PASE as time goes by, porting IBM i environments to something other than POWER (if IBM were ever inclined) has become closer to being as hard as porting AIX – which is to say, as hard as any other operating system. TIMI has evolved from a genuine source of portability (which greatly aided IBM in the CISC-to-RISC transition) into being little more than a historical vestige and form of backward-compatibility.

by KMag 5y ago

snovv_crash 5y ago

iOS already supports bitcode deployments to the app store, I believe this is the direction they are taking to solve this problem.

KMag 5y ago
Very nice. I hope that in the future, native code will be the distribution format about as often as we write inline assembly. Sometimes you'll really need precise control over instructions, but for 99% of code, it's not worth the cost in giving up long-term technology improvements. In particular, x86's total store ordering memory model causes some memory fences to disappear at the machine code level. The Aarch64 relaxed memory model allows for lower cache synchronization overhead, but code with correct memory fences compiled to x86 loses this information, requiring overly conservative binary translation/higher overhead TSO mode in Aarch64 binary translators. These days, hardware acquire/release/full flavors of memory fences better match the C++ and Java memory models, but some hardware has load/store/full flavors of memory fences. Binary translation across these flavors means changing all fences to full fences, or else some static analysis that's far beyond anything I'm aware existing at this time.
- saagarjha 5y ago
  Or just specialized hardware to do the TSO…
  - KMag 5y ago
    One could, but then one would give up the advantages of a relaxed memory model.
masklinn 5y ago
Afaik bitcode remains architecture-dependent, so bitcode deployments is mostly do they can re-optimise, and a convenient component of app slicing (if they end up generating the final bundle anyway, having more visibility into what’s what is useful).
- KMag 5y ago
  I think re-targeting bitcode for a different architecture with the same pointer size and endinness is a pretty light weight operation, but I might be wrong. I'm pretty sure it's orders of magnitude lower overhead and less complicated than dynamically recompiling native code.
  - masklinn 5y ago
    Oh for sure.
- qznc 5y ago
  With C/C++ the preprocessor makes architecture-dependent decisions. Bitcode has no chance to fix that.
  - Spivak 5y ago
    So this is true but also not that relevant, bitcode is your architecture.

why_only_15 5y ago

Apple hasn't employed Chris Lattner since January 2017: http://nondot.org/~sabre/Resume.html http://nondot.org/~sabre/Resume.html

skissane 5y ago

> This is great for x86, but for low-overhead multi-platform binaries, IBM came up with a pretty good solution decades ago with OS/400 TIMI (Technology Independent Machine Interface), which is basically Android Runtime's install-time native code generation, but suitable as a C/RPG/COBOL/CL compilation target and not mandating a garbage collector. To be honest, I think the dream of portability which TIMI represented is mostly dead in recent IBM i versions. More and more functionality depends on the AIX compatibility environment, PASE, which doesn't run under TIMI, it is full of standard AIX XCOFF binaries containing POWER machine code. (Interspersed with calls to IBM i-specific APIs which allow PASE binaries to access services provided by code running inside and underneath TIMI.) Given the increasing use of PASE as time goes by, porting IBM i environments to something other than POWER (if IBM were ever inclined) has become closer to being as hard as porting AIX – which is to say, as hard as any other operating system. TIMI has evolved from a genuine source of portability (which greatly aided IBM in the CISC-to-RISC transition) into being little more than a historical vestige and form of backward-compatibility.