Hacker News Reader

Comment by macavity23 | Hacker News Reader

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.

View on HN

Objective-C was created in 1983.

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.

You left out SPARC and PA-RISC. NeXTSTEP was probably the most cross-platform desktop OS ever sold.

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.

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.

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.

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.

> 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.

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.

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%.

Reply on news.ycombinator.com