Have a look here
http://www.peter-cockerell.net/aalp/html/ch-3.html

3.5 Group four - branch
Subsection - Offsets and pipelining


Ohh - And sorry my crystalball wasn't able to tell what type of arm MCU 
you use.

/Bingo

Disassembling object files might not show the same machine code as later 
is placed in memory, since relocations are not yet applied to it. In 
case of the BNE instruction, there could be a relocation record in the 
object file which associates the instruction with the symbolic target 
"loop" and the exact machine code is updated by the linker, or in other 
cases by the operating system loader.

Hi Bingo,
 thanks for you reply, the target processor is actually software 
emulated, but based on an arm2 instruction set.

I was able to figure out the ((instruction value) x Wordsize)+(pipeline 
length) so I tried adding more code in the vector table area only to 
find more strange output. I can't see how fffffe translates to 0x20?

memoryInitProgram.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <main-0x20>:
   0:  eafffffe   b  20 <main>
  ...

00000020 <main>:
  20:  e3a01902   mov  r1, #32768  ; 0x8000
  24:  e3a02c01   mov  r2, #256  ; 0x100
  28:  e3a00000   mov  r0, #0

0000002c <loop>:
  2c:  e1a00000   nop      ; (mov r0, r0)
  30:  e1a00000   nop      ; (mov r0, r0)
  34:  e1a00000   nop      ; (mov r0, r0)
  38:  e1a00000   nop      ; (mov r0, r0)
  3c:  e4810004   str  r0, [r1], #4
  40:  e2422001   sub  r2, r2, #1
  44:  1a000009   bne  2c <loop>
asdka@asdka-laptop:~/softprocessor/testARMcode$

The output of
  objdump -r ...
shows the relocation records. However you'd better link the program and 
then look at the code.

Thanks for the tips, the trouble is, this is for testing a software 
emulation of an arm processor and I really dont want extra code getting 
linked in when there isn't support for it (yet).

 I checked the source code and there was a .global directive at the top 
of the file, this must be telling the assembler to designate the code as 
relocatable. I removed this an it all makes much more sense.

asdka@asdka-laptop:~/softprocessor/testARMcode$ 
/home/asdka/armbinutils/bin/arm-elf-objdump -d memoryInitProgram.o

memoryInitProgram.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <main-0x20>:
   0:  ea000006   b  20 <main>
  ...

00000020 <main>:
  20:  e3a01902   mov  r1, #32768  ; 0x8000
  24:  e3a02c01   mov  r2, #256  ; 0x100
  28:  e3a00000   mov  r0, #0

0000002c <loop>:
  2c:  e1a00000   nop      ; (mov r0, r0)
  30:  e1a00000   nop      ; (mov r0, r0)
  34:  e1a00000   nop      ; (mov r0, r0)
  38:  e1a00000   nop      ; (mov r0, r0)
  3c:  e4810004   str  r0, [r1], #4
  40:  e2422001   sub  r2, r2, #1
  44:  1a000009   bne  2c <loop>

Looks exactly as before. Copy and paste error?

You really should check the binutils' manual to find out whether as is 
actually able to produce unrelocated code, and if so, how, if you indent 
to analyse and perhaps run .o based code. Otherwise you might just end 
with a section based relocation instead of a symbol based relocation, in 
places where absolute addresses are encoded instead of relative 
addresses.

I will do, I have much to learn about how assemblers actually work. 
There is only 1 difference in the disassembled files and it is at 
location 0.