How to write assembly code for the iPhone

One good option for more portable macros in assembly is to use the C preprocessor. It doesn't always provide all the features you might like, but its behavior is defined by a standard, so it is very predictable.

The iOS toolchain applies the C preprocessor to assembly sources by default; it's been a while since I've used the mainline gnu tools, but I think it is automatically applied to .S (capital S) files by default there.

If you have more questions or issues with the iOS toolchain, please file bugs and/or post your question to the devforums. There are plenty of people who use assembler everyday who will be happy to help out.

And just to echo grandparent: the unified assembler language has been standard on ARM for several years now; pre-unified mnemonics like strneb are deprecated.

As I had hoped was clear from context (but I guess wasn't), I was definitly implementing these features for the assembler. In addition to being a better result (for example, requiring fewer changes to the compiler I was also spending a lot of time trying to get cobbled together out or Apple's fork of gcc 4.0, mainline gcc 4.2, and the LLVM gcc 4.2 project that, while generated horribly broken code due to LLVM being a horrible target for ARM, had a ton of Apple internal patches; alternatively one could edit every app that required these features to mess with a preprocessor, but that would scale horribly), it was actually much easier to do... implementing the full gas macro system outside of gas and its assembly parser seems unneccessarily brutal: often you just needed to fix tiny things, like "this argument is now optional" or "you can now specify this as a variable".

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

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.