5 ms·

Older enough programmers will remember the DEC Vax to Alpha binary translators. When DEC produced the Alpha you could take existing Vax binaries, run them throu

by jws 13y ago

Older enough programmers will remember the DEC Vax to Alpha binary translators. When DEC produced the Alpha you could take existing Vax binaries, run them through a tool, and have a shiny new Alpha binary ready to go.¹ Given such a tool, which existed in 1992, it seems simple enough to do the recompile once on the first launch and cache it. Executable code is a vanishingly small bit of the disk use of an OS X machine. Going forward, Apple has a long experience with fat binaries for architecture changes. 68k→PPC, PPC→IA32, IA32→x86-64. I don't think x86-64→ARM8 is anything more than a small bump in the road. As far as shipping LLVM and letting the machines do the last step, that should make software developers uncomfortable. Recall that one of the reasons OpenBSD needs so much money² for their build farm is because they keep a lot of architectures going because bugs show up in the different backends. I know I want to have tested the exact stream of opcodes my customer is going to get. ␄ ¹ I think there was also a MIPS to Alpha tool for people coming from that side. ² In the sense that some people think $20k/yr for electricity is a lot.

jey 13y ago
Yep, and Apple has already done dynamic binary translation once before, during the PPC to x86 switch.
- BruceM 13y ago
  And 68k to PPC.
theatrus2 13y ago
This was also the entire premise of the Transmeta CPUs
pjmlp 13y ago
> As far as shipping LLVM and letting the machines do the last step, that should make software developers uncomfortable. Why? This is how Windows Phone 8 works (MDIL) and Android will as well (ART). On WP 8 case, MDIL are ARM/x86 binaries just with symbolic names left in the executable. The symbolic names are resolved into memory addresses at installation time, by a simplified on device linker. Android's ART, already made default on the public development tree, compiles dex to machine code on device installation.
wsc981 13y ago
Going forward, Apple has a long experience with fat binaries for architecture changes. 68k→PPC, PPC→IA32, IA32→x86-64. I don't think x86-64→ARM8 is anything more than a small bump in the road. Using the lipo[0] tool provided as part of the Apple Developer tools, it's pretty easy for any developer to create a x86/ARM fat binary. Many iOS developers have used this technique to create libraries that work on both the iOS simulator as well as a iOS device. [0]: http://ss64.com/osx/lipo.html http://ss64.com/osx/lipo.html

by jws 13y ago

jey 13y ago

Yep, and Apple has already done dynamic binary translation once before, during the PPC to x86 switch.

BruceM 13y ago
And 68k to PPC.

theatrus2 13y ago

This was also the entire premise of the Transmeta CPUs

pjmlp 13y ago

> As far as shipping LLVM and letting the machines do the last step, that should make software developers uncomfortable. Why? This is how Windows Phone 8 works (MDIL) and Android will as well (ART). On WP 8 case, MDIL are ARM/x86 binaries just with symbolic names left in the executable. The symbolic names are resolved into memory addresses at installation time, by a simplified on device linker. Android's ART, already made default on the public development tree, compiles dex to machine code on device installation.

wsc981 13y ago

Going forward, Apple has a long experience with fat binaries for architecture changes. 68k→PPC, PPC→IA32, IA32→x86-64. I don't think x86-64→ARM8 is anything more than a small bump in the road. Using the lipo[0] tool provided as part of the Apple Developer tools, it's pretty easy for any developer to create a x86/ARM fat binary. Many iOS developers have used this technique to create libraries that work on both the iOS simulator as well as a iOS device. [0]: http://ss64.com/osx/lipo.html http://ss64.com/osx/lipo.html