7 ms·

How to write assembly code for the iPhone

48 points by frr149 14y ago

ksec 14y ago
Interesting that After all these years Compiler still haven't catch up with self written Assembly speed. Or is there some LLVM optimization not used yet?
- stephencanon 14y ago
  Compilers and assembly programmers serve two different roles. - A compiler is expected to produce reasonably fast code in microseconds. - An assembly programmer is expected to produce the fastest code possible in hours or days or weeks. Given hours or days, and development work focused on such a task, compilers would be able to compete with good assembly programmers; it simply hasn't been the focus of much compiler development, because most users don't want to wait three days for their code to compile. What's remarkable is that compilers are able to fairly consistently beat assembly programmers of average skill, while delivering results thousands of times faster.
z3phyr 14y ago
I ve heard that ARM assembly is easier to grasp than x86..
- arthulia 14y ago
  http://www-cs-faculty.stanford.edu/~eroberts/courses/soco/projects/risc/risccisc/ http://www-cs-faculty.stanford.edu/~eroberts/courses/soco/pr... That is probably because there are fewer instructions to memorize.
- sparky 14y ago
  ARM is still a bit icky, but nearly anything this side of a VAX mainframe will be easier to grasp than x86. If anyone's looking to learn, MIPS is really easy to pick up. There's a good simulator (SPIM[1]) with terminal and GUI interfaces and lots of tutorials, as it's used in a lot of undergrad computer architecture courses. [1] http://spimsimulator.sourceforge.net/ http://spimsimulator.sourceforge.net/
  - pjmlp 14y ago
    As I grew up with x86 I beg to differ.
    - mahmud 14y ago
      Opinions are trivial to hold. Backing them up, OTOH, is an entirely different matter. "x86" instructions now number in the hundreds. Almost any RISC ISA will max at 30% of that, with less than half of the addressing modes. "Easy" is an adjective, but "easier" is an ordering relation: ARM is easier than x86.
      - pjmlp 14y ago
        I still beg to differ. I find confusing the three parameter mode of many ARM instructions and the possibility to have multiple execution modes. I did Z80, x86, 6800 and MIPS programming back in the day.
      - brigade 14y ago
        ARM has a lot of instructions too. Exactly how many depends on how you count them - are pld and pldw different instructions? mov and movw? uadd16 and sadd16? vadd.i16 and vadd.i8? vadd.f32 <Dd>, <Dn>, <Dm> and vadd.f32 <Sd>, <Sn>, <Sm>? Conservatively (relative to x86 where I'd imagine everyone counts pavgb and pavgw as separate instructions), ARM has well over 300 instructions. Include significantly different permutations of instructions, and you're easily over 500, and probably outnumbers x86. Even if you discount vector and floating point, ARM still has around a hundred distinct instructions.
      - stephencanon 14y ago
        ARMv7 has 426 distinct instructions (counting sections in the architecture reference manual). x86 does have somewhat more instruction names, but not dramatically more (and the blowup is largely because of differences in naming conventions; Intel, for instance uses different names for [vector|scalar][single|double]float operations, whereas they are all the same name on ARM). What makes ARM nicer (and it is somewhat nicer, in my experience as someone who spends hundreds of hours writing assembly code for both architectures every year) is: 1. non-destructive operations (finally coming to Intel too!) 2. better orthogonality, fewer weird holes in the ISA (especially in the vector ops) 3. no piecemeal vector extensions (all the various extensions that may or may not be available on x86 are madness). When you really get down to it, though, none of these make a huge difference; they're just niceties.
chj 14y ago
Writing assembler for iPhone is a pain in the ass. I don't know which version its gas is based on, but it is definitely a very very old one. The most important feature missing is to create a macro that takes arguments. A most recent change is that some guy in Apple decided to switch conditional instructions like ldrneb to ldrbne, ruining my existing code base (> 10K lines). Now I need to remember what's the right way for iPhone, and what's for Android. Btw: there is zero support from Apple, so your only chance is to find this kind of blog posts, and they are very few. Bookmark it now if you may need it someday.
- __float 14y ago
  10K lines? Can you elaborate a little on what this is used for? I am having trouble seeing why Obj-C (it is just C after all) can't be used for the majority.
  - chj 14y ago
    C is sufficient for most apps, however, what I am working on happens to be in the rare few --- x86 emulator(http://www.aemula.net http://www.aemula.net). We need to make good use of every register and the overhead of function call is considered unacceptable.
- brigade 14y ago
  There is documentation of the OS X assembler [1] that generally applies on iOS as well. In particular, you can have macros with up to 10 arguments, numbered $0 to $9. (actually this shown in the article...) I'm pretty sure ldrneb was never a valid instruction; gnu as tended to be more flexible than ARM's specification of the assembly language. Some of this flexibility used to be allowed by ARM (maybe), the rest was depreciated with UAL and llvm only supports ARM's UAL syntax. You can get this behaviour from GNU as via .syntax unified (which you really ought to be using, since it makes it really easy to support assembling to both ARM and Thumb-2) [1] https://developer.apple.com/library/mac/#documentation/DeveloperTools/Reference/Assembler/000-Introduction/introduction.html https://developer.apple.com/library/mac/#documentation/Devel...
  - 14y ago
panic 14y ago
Your C compiler can also generate NEON instructions if you use NEON intrinsics: http://gcc.gnu.org/onlinedocs/gcc/ARM-NEON-Intrinsics.html http://gcc.gnu.org/onlinedocs/gcc/ARM-NEON-Intrinsics.html http://blog.llvm.org/2010/04/arm-advanced-simd-neon-intrinsics-and.html http://blog.llvm.org/2010/04/arm-advanced-simd-neon-intrinsi...

48 points by frr149 14y ago

ksec 14y ago

Interesting that After all these years Compiler still haven't catch up with self written Assembly speed. Or is there some LLVM optimization not used yet?

stephencanon 14y ago
Compilers and assembly programmers serve two different roles. - A compiler is expected to produce reasonably fast code in microseconds. - An assembly programmer is expected to produce the fastest code possible in hours or days or weeks. Given hours or days, and development work focused on such a task, compilers would be able to compete with good assembly programmers; it simply hasn't been the focus of much compiler development, because most users don't want to wait three days for their code to compile. What's remarkable is that compilers are able to fairly consistently beat assembly programmers of average skill, while delivering results thousands of times faster.

z3phyr 14y ago

I ve heard that ARM assembly is easier to grasp than x86..

arthulia 14y ago
http://www-cs-faculty.stanford.edu/~eroberts/courses/soco/projects/risc/risccisc/ http://www-cs-faculty.stanford.edu/~eroberts/courses/soco/pr... That is probably because there are fewer instructions to memorize.
sparky 14y ago
ARM is still a bit icky, but nearly anything this side of a VAX mainframe will be easier to grasp than x86. If anyone's looking to learn, MIPS is really easy to pick up. There's a good simulator (SPIM[1]) with terminal and GUI interfaces and lots of tutorials, as it's used in a lot of undergrad computer architecture courses. [1] http://spimsimulator.sourceforge.net/ http://spimsimulator.sourceforge.net/
- pjmlp 14y ago
  As I grew up with x86 I beg to differ.
  - mahmud 14y ago
    Opinions are trivial to hold. Backing them up, OTOH, is an entirely different matter. "x86" instructions now number in the hundreds. Almost any RISC ISA will max at 30% of that, with less than half of the addressing modes. "Easy" is an adjective, but "easier" is an ordering relation: ARM is easier than x86.
    - pjmlp 14y ago
      I still beg to differ. I find confusing the three parameter mode of many ARM instructions and the possibility to have multiple execution modes. I did Z80, x86, 6800 and MIPS programming back in the day.
    - brigade 14y ago
      ARM has a lot of instructions too. Exactly how many depends on how you count them - are pld and pldw different instructions? mov and movw? uadd16 and sadd16? vadd.i16 and vadd.i8? vadd.f32 <Dd>, <Dn>, <Dm> and vadd.f32 <Sd>, <Sn>, <Sm>? Conservatively (relative to x86 where I'd imagine everyone counts pavgb and pavgw as separate instructions), ARM has well over 300 instructions. Include significantly different permutations of instructions, and you're easily over 500, and probably outnumbers x86. Even if you discount vector and floating point, ARM still has around a hundred distinct instructions.
    - stephencanon 14y ago
      ARMv7 has 426 distinct instructions (counting sections in the architecture reference manual). x86 does have somewhat more instruction names, but not dramatically more (and the blowup is largely because of differences in naming conventions; Intel, for instance uses different names for [vector|scalar][single|double]float operations, whereas they are all the same name on ARM). What makes ARM nicer (and it is somewhat nicer, in my experience as someone who spends hundreds of hours writing assembly code for both architectures every year) is: 1. non-destructive operations (finally coming to Intel too!) 2. better orthogonality, fewer weird holes in the ISA (especially in the vector ops) 3. no piecemeal vector extensions (all the various extensions that may or may not be available on x86 are madness). When you really get down to it, though, none of these make a huge difference; they're just niceties.

chj 14y ago

Writing assembler for iPhone is a pain in the ass. I don't know which version its gas is based on, but it is definitely a very very old one. The most important feature missing is to create a macro that takes arguments. A most recent change is that some guy in Apple decided to switch conditional instructions like ldrneb to ldrbne, ruining my existing code base (> 10K lines). Now I need to remember what's the right way for iPhone, and what's for Android. Btw: there is zero support from Apple, so your only chance is to find this kind of blog posts, and they are very few. Bookmark it now if you may need it someday.

__float 14y ago
10K lines? Can you elaborate a little on what this is used for? I am having trouble seeing why Obj-C (it is just C after all) can't be used for the majority.
- chj 14y ago
  C is sufficient for most apps, however, what I am working on happens to be in the rare few --- x86 emulator(http://www.aemula.net http://www.aemula.net). We need to make good use of every register and the overhead of function call is considered unacceptable.
brigade 14y ago
There is documentation of the OS X assembler [1] that generally applies on iOS as well. In particular, you can have macros with up to 10 arguments, numbered $0 to $9. (actually this shown in the article...) I'm pretty sure ldrneb was never a valid instruction; gnu as tended to be more flexible than ARM's specification of the assembly language. Some of this flexibility used to be allowed by ARM (maybe), the rest was depreciated with UAL and llvm only supports ARM's UAL syntax. You can get this behaviour from GNU as via .syntax unified (which you really ought to be using, since it makes it really easy to support assembling to both ARM and Thumb-2) [1] https://developer.apple.com/library/mac/#documentation/DeveloperTools/Reference/Assembler/000-Introduction/introduction.html https://developer.apple.com/library/mac/#documentation/Devel...
- 14y ago

panic 14y ago

Your C compiler can also generate NEON instructions if you use NEON intrinsics: http://gcc.gnu.org/onlinedocs/gcc/ARM-NEON-Intrinsics.html http://gcc.gnu.org/onlinedocs/gcc/ARM-NEON-Intrinsics.html http://blog.llvm.org/2010/04/arm-advanced-simd-neon-intrinsics-and.html http://blog.llvm.org/2010/04/arm-advanced-simd-neon-intrinsi...