Lpc2000

I am using the GNU toolchain and I want to do some ARM assembler code
for an FIQ handler that must be lean and mean.

I must say that the ARM documentation for the assembler seems to be
pretty thin and cryptic (hint, does anybody know a good guide to ARM7
assembler ;-)

Anyway, more or less I have got the grasp of it, including the fact
that it only does single word instructions and it is therefore
impossible to load a 32bit constant. I have seen that there are ways
to load parts of a word, and thus form a 32bit constant with several
instructions.

But my problem is getting a C pointer into a register. For example I
have a global C pointer thus:

int *foo;

so I would expect the adress of foo to be a constant _foo to the
assembler. Now I would like to load the contents of the adress _foo
into a register.

Looking around at the few code snippetts I was able to find, I noticed
the use of instructions like:

ldr rd,=0x12345678

I cannot find any form of this apparant 32 bit immediate adressing
mode in the assembly tables. How does it work? Are there limitations?

Better still, what is the best way to achieve my goal (getting the
contents of a global C pointer variable into a register). It must be a
very common requirement!

> Looking around at the few code snippetts I was able to find, I noticed
> the use of instructions like:
> 
> ldr rd,=0x12345678
> 
> I cannot find any form of this apparant 32 bit immediate adressing
> mode in the assembly tables. How does it work? Are there limitations?
> 

You are correct, you can not load a 32 bit immediate constant,
regardless of what the code looks like.  But, what you can do is load
a 32 bit constant from a 'literal pool' using PC relative addressing.

So, the compiler generates a block (pool) of constants as it goes
along and actually generates a PC relative load from the pool.

Ordinarily, the compiler would rather calculate the constant in 3
arithmetic operations than use the 'literal pool' so you will see a
lot of address calculation just to get to the VIC.

I imagine it is possible to specify an optimization that will cause
more 'literal pool' operations and less address calculations - perhaps
optimize for size.

Richard