3 ms·

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 develope

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

by catch23 14y ago

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.