4 ms·

A question for iOS devs out there: how tied to ARM is iOS Objective-C programming? I ask because Android already supports Atom-based devices, and presumably Wi

A question for iOS devs out there: how tied to ARM is iOS Objective-C programming? I ask because Android already supports Atom-based devices, and presumably Win8RT apps are easy to recompile for Intel - so it seems likely that it would be straightforward for any of the players in the mobile space to switch architectures on fairly short notice.

melling 14y ago
Objective-C was created in 1983. http://en.wikipedia.org/wiki/Objective-C http://en.wikipedia.org/wiki/Objective-C Apple and NeXTStep have run on Intel, Motorola 68k, or PowerPC chips in the past. iOS is a subset of Mac OS, which currently runs on Intel. In short, the CPU architecture choice is irrelevant.
- deleted 14y ago
  [deleted]
- wtallis 14y ago
  You left out SPARC and PA-RISC. NeXTSTEP was probably the most cross-platform desktop OS ever sold.
ConstantineXVI 14y ago
As mentioned, Apple has plenty of experience switching architectures, so technically it's not a huge issue. Don't hold your breath though; since Apple's going out of it's way to build custom ARM cores now, it's safe to assume ARM (or if anything, a custom arch sooner than Intel) is their future now. Apple got burned when IBM couldn't keep up power/performance on PowerPC, leaving their fate entirely to a third-party is a mistake they're unlikely to make again.
yk 14y ago
Not an iOS dev, so I can not tell you how much inline assembler magic is in apps. But the operating system needs of course a fair amount of plattform specific code, as does the compiler. And in general quite a few optimizations are platform specific. So even though Apple uses llvm, the swap is a lot more involved than a -march=x64 compiler flag. This is also true for Android and WinRT.
- catch23 14y ago
  Almost no libraries out there have inline assembler magic. If you wrote a library with inline assembler, you'd have to write it for arm & i386 so that developers could still use it in the simulator. There are very few people out there competent in both assembly languages who are also iOS developers. The need is also pretty low because if you want fast computations, you'd do it in the GPU. The only need might be some bit-banging code for interfacing with external hardware. So the only people who might need assembly are making complicated interface hardware.
  - dietrichepp 14y ago
    There are plenty of cases where the cost and complexity of sending code to the GPU means that you use processor intrinsics to speed up your code. As far as I know, most people still do encoding/decoding of audio/images/video on the CPU, unless there's a hardware codec available. Audio DSP is mostly done on the CPU too, I think. Audio is a bit more demanding than graphics in terms of bit depth — the "highp" precision should be taken as a minimum precision for audio work, it's not always available in the fragment shader, and it's definitely not enough precision for audio production apps like Garage Band.
  - asveikau 14y ago
    > The only need might be some bit-banging code for interfacing with external hardware. Atomic primitives are another reason to do inline assembly, though since recent GCC (and probably LLVM - though I haven't looked into it) provides CPU-agnostic atomic ops this isn't as big a deal as it used to be. (C++11 also probably would help, though I'm not sure how the adoption has been in mobile SDKs.) Pretty sure inline asm is also still common for SIMD ops. Although the sane approach there would be to have a generic C implementation to fall back on if there is no optimized one present.
    - dietrichepp 14y ago
      Clang and GCC both have new atomic built-ins that can be used for implementing C11 or C++11 atomics. You can use them whether or not you have C++11 support. But I don't see much inline asm for SIMD ops. Almost every piece of SIMD code I see uses either intrinsics or writes the whole function in assembly.
catch23 14y ago
I doubt a manufacturer will switch chips because it has better power consumption. There are lots of other power hungry components in a mobile phone. I'm guessing the CPU might only use up 15% of the total power consumption, so a CPU with half the power consumption would really only increase battery life by 7%.

melling 14y ago

Objective-C was created in 1983. http://en.wikipedia.org/wiki/Objective-C http://en.wikipedia.org/wiki/Objective-C Apple and NeXTStep have run on Intel, Motorola 68k, or PowerPC chips in the past. iOS is a subset of Mac OS, which currently runs on Intel. In short, the CPU architecture choice is irrelevant.

deleted 14y ago
[deleted]
wtallis 14y ago
You left out SPARC and PA-RISC. NeXTSTEP was probably the most cross-platform desktop OS ever sold.

ConstantineXVI 14y ago

As mentioned, Apple has plenty of experience switching architectures, so technically it's not a huge issue. Don't hold your breath though; since Apple's going out of it's way to build custom ARM cores now, it's safe to assume ARM (or if anything, a custom arch sooner than Intel) is their future now. Apple got burned when IBM couldn't keep up power/performance on PowerPC, leaving their fate entirely to a third-party is a mistake they're unlikely to make again.

yk 14y ago

Not an iOS dev, so I can not tell you how much inline assembler magic is in apps. But the operating system needs of course a fair amount of plattform specific code, as does the compiler. And in general quite a few optimizations are platform specific. So even though Apple uses llvm, the swap is a lot more involved than a -march=x64 compiler flag. This is also true for Android and WinRT.

catch23 14y ago
Almost no libraries out there have inline assembler magic. If you wrote a library with inline assembler, you'd have to write it for arm & i386 so that developers could still use it in the simulator. There are very few people out there competent in both assembly languages who are also iOS developers. The need is also pretty low because if you want fast computations, you'd do it in the GPU. The only need might be some bit-banging code for interfacing with external hardware. So the only people who might need assembly are making complicated interface hardware.
- dietrichepp 14y ago
  There are plenty of cases where the cost and complexity of sending code to the GPU means that you use processor intrinsics to speed up your code. As far as I know, most people still do encoding/decoding of audio/images/video on the CPU, unless there's a hardware codec available. Audio DSP is mostly done on the CPU too, I think. Audio is a bit more demanding than graphics in terms of bit depth — the "highp" precision should be taken as a minimum precision for audio work, it's not always available in the fragment shader, and it's definitely not enough precision for audio production apps like Garage Band.
- asveikau 14y ago
  > The only need might be some bit-banging code for interfacing with external hardware. Atomic primitives are another reason to do inline assembly, though since recent GCC (and probably LLVM - though I haven't looked into it) provides CPU-agnostic atomic ops this isn't as big a deal as it used to be. (C++11 also probably would help, though I'm not sure how the adoption has been in mobile SDKs.) Pretty sure inline asm is also still common for SIMD ops. Although the sane approach there would be to have a generic C implementation to fall back on if there is no optimized one present.
  - dietrichepp 14y ago
    Clang and GCC both have new atomic built-ins that can be used for implementing C11 or C++11 atomics. You can use them whether or not you have C++11 support. But I don't see much inline asm for SIMD ops. Almost every piece of SIMD code I see uses either intrinsics or writes the whole function in assembly.

catch23 14y ago

I doubt a manufacturer will switch chips because it has better power consumption. There are lots of other power hungry components in a mobile phone. I'm guessing the CPU might only use up 15% of the total power consumption, so a CPU with half the power consumption would really only increase battery life by 7%.