
How to write assembly code for the iPhone - frr149
http://www.shervinemami.info/armAssembly.html#howto
======
chj
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.

~~~
saurik
Apple (NextSTEP, really) forked their version of gas so long ago that it
predates the formation of "GNU binutils". While Apple has occasionally gone
back and merged updates for some files, as far as I've been able to tell, most
of the code has been stagnant since ~1990. The version of GAS they are using
is pretty much 1.38. :(

(One of the most irritating things I had to do while supporting all of the
initial iPhone jailbreak efforts was to reimplement a ton of gas macro
features from later versions of the assembler so I could compile the "normal
programs" that people expected to work on this system.)

~~~
stephencanon
The current Apple devtools default to using the (much more modern) llvm-mc
assembler, not gas. Patches and bug reports are always welcome!

~~~
saurik
FWIW, this would not have particularly helped me (even with a time machine to
take the current compilation chain back to when we are talking about, which is
December of 2007), as Clang is unable to compile a bunch of the kinds of
things I need to compile (it barely often even compiles my stuff correctly:
the compiler itself often crashes; this was certainly the case a few years
ago, when the project we are discussing was actually relevant... arguably my
main contribution to the iOS toolchain community was to do the work required
to get us off of the LLVM compiler and onto mainline gcc).

To the extent to which that is then some kind of veiled challenge or poke (as
I'm having a very difficult time understanding why you are telling me to do
something now when I've been talking about work I did five years ago, although
work that I still rely on), I will then make the counter-poke: GCC is open
source, as is gas; it is certainly the case that "patches and bug reports are
always welcome". Just because something exists does not mean it is entitled to
"patches and bug reports" when there are better alternatives. I personally
have no real interest in being able to use Apple's off-the-shelf toolchain,
nor do I appreciate their reasons for forking so far.

A key problem here, of course, is that many people in the Apple development
community have a strong negative impression of both GCC and GAS; but, as far
as I can tell, this is almost entirely the fault (and probably strategic plan)
of Apple, who have been working with a 5-year old version of GCC hooked up to
a 20-year old version of GAS. It is incredibly painful for me to see all of
this great work and effort being ignored and rewritten from scratch by a new
generation of people whom Apple have brainwashed into thinking this is then a
technical issue and not a licensing one.

Regardless, in my attempts (two weeks ago) to use LLVM MC (disassembler), I
found a handful of issues that I had to fix (on SVN head) to get it to even
generate correct disassembly (although one or two of the bugs were in the
table definitions and should also affect assembly) on the first project I
tried to disassemble with it: I thought it would even be a simple case (a
bootrom, which would thereby have no relocations or anything particularly
tricky to understand or decode: just some instructions).

The result of that is, from being on the IRC channel (where after having a
vague discussion about some MC API and usage issues, I attempted to bring up
some of these bugs), I did and still do not get the impression that anyone
there really seems to care about these kinds of encoding issues, so the bugs I
found are likely just going to rot.

Honestly, I do not feel even remotely bad about this, because binutils (which
I have already recoded my project to use instead) does not have any of these
issues, and is also open source. I really believe that Apple's forking of the
community efforts are harmful to the cause, and I would frankly rather not
encourage their behavior: if they want their toolchain to work well, and they
want my help to make that happen, they are going to need to accept the
licensing requirements of GCC; otherwise, I'm quite happy to watch them have
to do all of the reimplementation work entirely on their own.

(Some might now point out that binutils doesn't provide all of the same data
that LLVM theoretically provides, but the way LLVM provides it is actually
sufficiently useless--in addition to being incorrect--that I do not mind. The
LLVM API, especially at the MC level, is highly overrated: it was seriously
sufficiently bad that I ended up in a situation where parsing the string
output it provides was more useful than attempting to extract meaning from
their MCInst objects. I could find the attitude "stop using that thing that
works and instead contribute patches to LLVM" defendable if LLVM were better
designed, but it sadly simply is not; it is slightly easier to use as a
library to do backend compilation, and it has better error reporting, but both
of these would have been simple and welcome contributions to gcc.)

------
panic
Your C compiler can also generate NEON instructions if you use NEON
intrinsics:

<http://gcc.gnu.org/onlinedocs/gcc/ARM-NEON-Intrinsics.html>

[http://blog.llvm.org/2010/04/arm-advanced-simd-neon-
intrinsi...](http://blog.llvm.org/2010/04/arm-advanced-simd-neon-intrinsics-
and.html)

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

~~~
sparky
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/>

~~~
pjmlp
As I grew up with x86 I beg to differ.

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

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

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

