4 ms·

The author claims this is not a legitimate reason: "Just ask any Mac developer". I'm assuming here he means that compilers can solve this problem for you (and

by ojilles 16y ago

The author claims this is not a legitimate reason: "Just ask any Mac developer". I'm assuming here he means that compilers can solve this problem for you (and hence don't incur a run time performance tax).

rbanffy 16y ago
He is wrong. While ARM is a good target, there are many variations, with different feature-sets, added instructions and JVM acceleration that make for really different targets (much like x86 and amd64) that he would have to upload and test independently. And I am talking about ARM, which is only the dominant mobile platform (and that wasn't dominant a couple tears ago). One may also consider x86 (lpia, maybe) and their own endless SSE variations.
bad_user 16y ago
Great ... so you're gonna build a dozen binaries (or more) and upload all of them to the App Store? That's rich.
- wmf 16y ago
  Actually, the compiler would output a single duodecimal-fat binary. (Analogous to quad-fat binaries from the NeXT days.)
  - bad_user 16y ago
    On a phone that has limited storage space? And there's another thing ... with Android I'm not sure if it will run correctly on a "Samsung Galaxy S" if I've only tested my app with the Nexus One, but at least I know it will execute. If you're reuploading an update for Samsung, it will surely not be one about binary-compatibility.
    - blasdel 16y ago
      iTunes could perform liposuction (seriously, `man 1 lipo`) on the app bundle when transferring to the device.
  - Tichy 16y ago
    But how does the compiler create binaries for CPUs that don't even exist yet?
vetinari 16y ago
It is actually a problem on Macs: there are entire libraries of applications, that will never run on any new Mac. PPC/Classic is not supported, PPC/OSX may or may not run, depending on the app. Forget 68K/Classic. (Yeah, I should have bought PC versions of Lucasfilm games, not the Mac ones.)
- wmf 16y ago
  Unofficial but works: http://www.macwindows.com/OS9_on_Intel_Mac.html http://www.macwindows.com/OS9_on_Intel_Mac.html
- jsnell 16y ago
  You can't run them on ScummVM?
  - rbanffy 16y ago
    And you just made the point for why use VMs ;-) Wouldn't it be nice to have a ScummVM that can run not only games but real applications?
  - vetinari 16y ago
    Yes, in this case, that's exactly what I do. But the point is that I shouldn't rely on group of volunteers to preserve compatibility. For Lucasfilm games it works, for others it doesn't (other "classic game", Diablo II, has PPC/Classic installer and PPC/Carbon update. It is uninstallable on current Macs). It is not just about games either - how many people were satisfied with Photoshop 7 (PPC/Classic), but they had to purchase newer version just to be compatible with their platform? Specifically Apple had quite a lot of ABI breaks in their history. But back to the article - it claimed, that architecture specific binaries are not a problem. I think, and many people agree, that having architecture independent binary is a good thing and provides real benefits not just to developers (fewer builds and reduced support), but to end-users too - compatibility with wide array of devices. You can develop for Snapdragon/Hummingbird (ARM) device and the same binary will run on Moorestown (IA32) or some random Freescale (PPC) too.
CountHackulus 16y ago
If you've ever written cross-platform code, especially between little and big endian machines, or even worse, different 64-bit implementations, then you know that compilers can't even come close to solving everything for you. Cross platform code needs lots of thought and hard work. THAT is why VM languages are nice. As for JITs, yes, they're getting much faster and much better at recognizing code to optimize. Then again, so are static compilers. But both of these technologies are slowly merging together. JITs are getting ahead of time compilation, and static compilers are getting profile directed compilations. You just have to ask yourself, is a 40% boost in performance worth hours, possibly weeks, of rewriting code for a different platform?
- pkaler 16y ago
  You don't need a VM to solve endian issues. This can be handled at the framework or library level. For example, the NSCoder class handles most of this for you in the OSX/iOS world. Conform to the NSCoding protocol and endian issues during serialization are handled for you.
  - vetinari 16y ago
    Many apps and libraries are ported, not written from scratch. You may not have an option to "conform to the NSCoding protocol", because you already have existing code, written before Apple Era.
bitwize 16y ago
Universal Binaries have made multi-architecture deployment a solved problem since the NeXT days.
- vetinari 16y ago
  Really? They did ARM7 builds at the time?

by ojilles 16y ago

rbanffy 16y ago

He is wrong. While ARM is a good target, there are many variations, with different feature-sets, added instructions and JVM acceleration that make for really different targets (much like x86 and amd64) that he would have to upload and test independently. And I am talking about ARM, which is only the dominant mobile platform (and that wasn't dominant a couple tears ago). One may also consider x86 (lpia, maybe) and their own endless SSE variations.

bad_user 16y ago

Great ... so you're gonna build a dozen binaries (or more) and upload all of them to the App Store? That's rich.

wmf 16y ago
Actually, the compiler would output a single duodecimal-fat binary. (Analogous to quad-fat binaries from the NeXT days.)
- bad_user 16y ago
  On a phone that has limited storage space? And there's another thing ... with Android I'm not sure if it will run correctly on a "Samsung Galaxy S" if I've only tested my app with the Nexus One, but at least I know it will execute. If you're reuploading an update for Samsung, it will surely not be one about binary-compatibility.
  - blasdel 16y ago
    iTunes could perform liposuction (seriously, `man 1 lipo`) on the app bundle when transferring to the device.
- Tichy 16y ago
  But how does the compiler create binaries for CPUs that don't even exist yet?

vetinari 16y ago

It is actually a problem on Macs: there are entire libraries of applications, that will never run on any new Mac. PPC/Classic is not supported, PPC/OSX may or may not run, depending on the app. Forget 68K/Classic. (Yeah, I should have bought PC versions of Lucasfilm games, not the Mac ones.)

wmf 16y ago
Unofficial but works: http://www.macwindows.com/OS9_on_Intel_Mac.html http://www.macwindows.com/OS9_on_Intel_Mac.html
jsnell 16y ago
You can't run them on ScummVM?
- rbanffy 16y ago
  And you just made the point for why use VMs ;-) Wouldn't it be nice to have a ScummVM that can run not only games but real applications?
- vetinari 16y ago
  Yes, in this case, that's exactly what I do. But the point is that I shouldn't rely on group of volunteers to preserve compatibility. For Lucasfilm games it works, for others it doesn't (other "classic game", Diablo II, has PPC/Classic installer and PPC/Carbon update. It is uninstallable on current Macs). It is not just about games either - how many people were satisfied with Photoshop 7 (PPC/Classic), but they had to purchase newer version just to be compatible with their platform? Specifically Apple had quite a lot of ABI breaks in their history. But back to the article - it claimed, that architecture specific binaries are not a problem. I think, and many people agree, that having architecture independent binary is a good thing and provides real benefits not just to developers (fewer builds and reduced support), but to end-users too - compatibility with wide array of devices. You can develop for Snapdragon/Hummingbird (ARM) device and the same binary will run on Moorestown (IA32) or some random Freescale (PPC) too.

CountHackulus 16y ago

If you've ever written cross-platform code, especially between little and big endian machines, or even worse, different 64-bit implementations, then you know that compilers can't even come close to solving everything for you. Cross platform code needs lots of thought and hard work. THAT is why VM languages are nice. As for JITs, yes, they're getting much faster and much better at recognizing code to optimize. Then again, so are static compilers. But both of these technologies are slowly merging together. JITs are getting ahead of time compilation, and static compilers are getting profile directed compilations. You just have to ask yourself, is a 40% boost in performance worth hours, possibly weeks, of rewriting code for a different platform?

pkaler 16y ago
You don't need a VM to solve endian issues. This can be handled at the framework or library level. For example, the NSCoder class handles most of this for you in the OSX/iOS world. Conform to the NSCoding protocol and endian issues during serialization are handled for you.
- vetinari 16y ago
  Many apps and libraries are ported, not written from scratch. You may not have an option to "conform to the NSCoding protocol", because you already have existing code, written before Apple Era.

bitwize 16y ago

Universal Binaries have made multi-architecture deployment a solved problem since the NeXT days.

vetinari 16y ago
Really? They did ARM7 builds at the time?