> .align 3 (by which I assume you mean align to a 2^3 boundary -- different 
> arm assemblers unfortunately put different interpretations on this 
> *groan*) has no meaning unless the section that it is placed in is also 
> guaranteed to be this aligned.  I can't speak for the ELF format off the 
> top of my head but this is not the case for a.out which only aligns 
> sections to a 4-byte boundary.  It also fills the instruction stream with 
> arbitrary padding that aren't guaranteed to be nop instructions (though I 
> think that they will normally have that effect with gas -- 0 == andeq r0, 
> r0, r0).   Don't forget that gcc emits conditional ldm...{...,pc} as well. 
>  Packing these out can really hose your performance.

That is a documentation issue.  As is the speed. If you turn on a workaround
it goes a bit slower and has some constraints. Oh Wow, thats like so unusual
I mean normally a workaround halves the program size and doubles the speed
right ?

I think that objection is a red herring except for the nops issue

> Yep, but updating it oughtn't to be that hard.  You need to find the 
> executable segment(s) and scan through them.  At the end of each will 
> normally be some spare bytes into which bogus instructions can be moved.

Normally isnt good enough really is it. It has to be always or never. Now
maybe the compilers job should just be to ensure the potential space
exists
 
> Yeah, this can be a pain.  If you are trying to build a large number of 
> programs (eg bootstrapping a complete netbsd/linux tree), then I really 
> think there is no substitute for getting a fixed chip.

Or doing some hacks at load time which is horrible but possible. Getting 
a fixed chip doesnt help people with surface mount IC's