Lpc2000

Hey guys, I've started working with the LPC2138. I'm still working 
through the docs, but one question I have is this:

PLLCFG  = (4 + (2 << 5));
   E3A0320E   mov r3, #0xE0000000
   E283397F   add r3, r3, #0x001FC000
   E2833084   add r3, r3, #0x00000084
   E3A02044   mov r2, #0x00000044
   E5C32000   strb r2, [r3]

I'm using CrossWorks with a Olimex JTAG (works great so far BTW) with 
optimization turned off.

ARM assembly still isn't clear to me yet, so this is probably buried in 
the technical docs somewhere.

Why doesn't this compile to something like:

mov r3, #0xE01FC084
mov r2, #0x00000044
strb r2, [r3]

Can't the ARM load a 32 bit immediate?

Thanks,

Brian

-- 
-----------------------------------------------------
Brian C. Lane (W7BCL)                      Programmer
www.shinemicro.com   RF, DSP & Microcontroller Design

> Hey guys, I've started working with the LPC2138. I'm still working 
> through the docs, but one question I have is this:
> 
> PLLCFG  = (4 + (2 << 5));
>    E3A0320E   mov r3, #0xE0000000
>    E283397F   add r3, r3, #0x001FC000
>    E2833084   add r3, r3, #0x00000084
>    E3A02044   mov r2, #0x00000044
>    E5C32000   strb r2, [r3]
> 
> I'm using CrossWorks with a Olimex JTAG (works great so far BTW) with 
> optimization turned off.
> 
> ARM assembly still isn't clear to me yet, so this is probably buried in 
> the technical docs somewhere.
> 
> Why doesn't this compile to something like:
> 
> mov r3, #0xE01FC084
> mov r2, #0x00000044
> strb r2, [r3]
> 
> Can't the ARM load a 32 bit immediate?

The opcode is 32-bits, so it can't also contain a 32-bit immediate.
But in this case, your number is only 8-bits, so it could probably
code an op-code for it.

The way I answer this type of question is to write C-code and
build it as you have done, and then recode what I think should
be possible in assembler and see if that builds. In the case
of 

 mov r3, #44

it'd probably compile, but

 mov r3, #12345678

it probably would not, but 

 mov r3, PLLVAL
 PLLVAL: .word #12345678

would (or whatever the assembler syntax is :), since this 
is loading a value using indirect addressing.

Dave

David Hawkins wrote:

> 
>  > Hey guys, I've started working with the LPC2138. I'm still working
>  > through the docs, but one question I have is this:
>  >
>  > PLLCFG  = (4 + (2 << 5));
>  >    E3A0320E   mov r3, #0xE0000000
>  >    E283397F   add r3, r3, #0x001FC000
>  >    E2833084   add r3, r3, #0x00000084
>  >    E3A02044   mov r2, #0x00000044
>  >    E5C32000   strb r2, [r3]
>  >
>  > I'm using CrossWorks with a Olimex JTAG (works great so far BTW) with
>  > optimization turned off.
>  >
>  > ARM assembly still isn't clear to me yet, so this is probably buried in
>  > the technical docs somewhere.
>  >
>  > Why doesn't this compile to something like:
>  >
>  > mov r3, #0xE01FC084
>  > mov r2, #0x00000044
>  > strb r2, [r3]
>  >
>  > Can't the ARM load a 32 bit immediate?
> 
> The opcode is 32-bits, so it can't also contain a 32-bit immediate.

That's what I suspected. How big of a number can you fit into a single MOV?

> But in this case, your number is only 8-bits, so it could probably
> code an op-code for it.

Yeah, the value to store is fine since its only 7 bits.

> 
> The way I answer this type of question is to write C-code and
> build it as you have done, and then recode what I think should
> be possible in assembler and see if that builds. In the case
> of
> 
> mov r3, #44
> 
> it'd probably compile, but
> 
> mov r3, #12345678
> 
> it probably would not, but
> 
> mov r3, PLLVAL
> PLLVAL: .word #12345678
> 
> would (or whatever the assembler syntax is :), since this
> is loading a value using indirect addressing.

Another related question - what's the difference between a LDR and a 
MOV? I understand the LDRH and LDRB for 16 and 8 bit loads, but don't 
see why there is a MOV if a LDR does the same thing?

Thanks,

Brian



-- 
-----------------------------------------------------
Brian C. Lane (W7BCL)                      Programmer
www.shinemicro.com   RF, DSP & Microcontroller Design

What is the mode your compiler is set to?  In THUMB mode all data 
must be 16 bits long.  ARM can add shifts to load some 32-bit values 
to registers, but not always.

Krys

--- In lpc2000@yahoogroups.com, "Brian C. Lane" <brian@s...> wrote:
> Hey guys, I've started working with the LPC2138. I'm still working 
> through the docs, but one question I have is this:
> 
> PLLCFG  = (4 + (2 << 5));
>    E3A0320E   mov r3, #0xE0000000
>    E283397F   add r3, r3, #0x001FC000
>    E2833084   add r3, r3, #0x00000084
>    E3A02044   mov r2, #0x00000044
>    E5C32000   strb r2, [r3]
> 
> I'm using CrossWorks with a Olimex JTAG (works great so far BTW) 
with 
> optimization turned off.
> 
> ARM assembly still isn't clear to me yet, so this is probably 
buried in 

> the technical docs somewhere.
> 
> Why doesn't this compile to something like:
> 
> mov r3, #0xE01FC084
> mov r2, #0x00000044
> strb r2, [r3]
> 
> Can't the ARM load a 32 bit immediate?
> 
> Thanks,
> 
> Brian
> 
> -- 
> -----------------------------------------------------
> Brian C. Lane (W7BCL)                      Programmer
> www.shinemicro.com   RF, DSP & Microcontroller Design

y4krys wrote:

> What is the mode your compiler is set to?  In THUMB mode all data
> must be 16 bits long.  ARM can add shifts to load some 32-bit values
> to registers, but not always.
> 

Its in ARM mode right now.

Brian

-- 
-----------------------------------------------------
Brian C. Lane (W7BCL)                      Programmer
www.shinemicro.com   RF, DSP & Microcontroller Design

Brian C. Lane <brian@...> schrieb am Thu, 25 Aug 2005 17:01:14 
-0700:

I strongly suggest to read ARM ARM (Architecture Reference Manual).


>
> That's what I suspected. How big of a number can you fit into a single 
> MOV?

8 Bits anywhere within 32bit.

Means e.g.:
mov	r1,#255
mov	r1,#0xff00
mov	r1,#0xff0000


> Another related question - what's the difference between a LDR and a
> MOV? I understand the LDRH and LDRB for 16 and 8 bit loads, but don't
> see why there is a MOV if a LDR does the same thing?

ARM is RISC and has a Load/Store architectur.

MOV = between registers.

LDR/STR =  register <=> memory (or memory mapped peripherals !)

Again, get ARM ARM and read it, it's worth it, and you get answers
faster :-)

If you still have questions, come back. But I also suggest to google
comp.sys.arm, many question have been answered there.

-- 
42Bastian Schick

Brian,
 This is how it looks compiled with my tools in the THUMB mode:

//  PLLCFG  = (4 + (2 << 5));

0x0000015E 4812 LDR R0,[PC,#0x048]  ; [0x1A8] =_A_PLLCFG (0xE01FC084)
0x00000160 2144 MOV R1,#68
0x00000162 6001 STR R1,[R0, #0]

My compiler has allocated a constant (address of PLLCFG) at 0x1A8 to 
avoid the limitation of the immediate operand size.  It looks like
your compiler prefers code generation over the data allocation.  Not 
all compilers are made equal ;-)).

Krys

--- In lpc2000@yahoogroups.com, "Brian C. Lane" <brian@s...> wrote:
> y4krys wrote:
> 
> > What is the mode your compiler is set to?  In THUMB mode all data
> > must be 16 bits long.  ARM can add shifts to load some 32-bit
values

> > to registers, but not always.
> > 
> 
> Its in ARM mode right now.
> 
> Brian
> 
> -- 
> -----------------------------------------------------
> Brian C. Lane (W7BCL)                      Programmer
> www.shinemicro.com   RF, DSP & Microcontroller Design

RE: [lpc2000] Beginner questions
> 
> I strongly suggest to read ARM ARM (Architecture Reference Manual).

The ARM-ARM is published by Addison-Wesley, and ARM does not
seem to post a copy of it on their web site, however, the
other day I stumbled across it on Altera's web site ...
(if these links get changed, just look for their Excalibur
devices documentation)

http://www.altera.com/literature/lit-exc.jsp

http://www.altera.com/literature/third-party/ddi0100e_arm_arm.pdf

Very nice of them :)

Dave

The differences between MOV and LDR are:

MOV is for moving data between registers, or moving a constant 
encoded into the instruction into a register.

LDR is a memory-access instruction that loads a value from memory 
into a register.

The second operand of a MOV may be shifted or rotated by a number of 
bits encoded into the instruction, or specified by the bottom byte of 
another register. The shift is carried out by dedicated hardware 
inline with the Op2 input into the ALU, so it has zero time overhead, 
unless of course the shift amount is specified in another register - 
in the ARM7 there are just two register read ports, so the processor 
stalls for one cycle while the shift amount is read from the register.

The shift/rotate hardware is used when extracting a constant encoded 
into a dataprocessing instruction (ADD, SUB, CMP, MOV etc). The 
encoding is "8 bits, optionally rotated right by an even number of 
bits" - so 8 bits anywhere in the 32-bit word isn't strictly accurate.

In the ARM assembler, a useful syntactical nicety is:
     MOV Rd,=0xfeedbeef
The assembler will turn this into a MOV or MVN if at all possible, 
otherwise it will create a literal pool entry and a pc-relative LDR 
instruction.

The only mildly reasonable argument for using three instructions to 
construct a constant rather than a pc-relative load from a literal 
pool, is that in a cached system it may turn out that the pc-relative 
load forces a cache-line eviction and reload... but that's not a very 
convincing argument to me.

Peter.

y4krys wrote:

> Brian,
> This is how it looks compiled with my tools in the THUMB mode:
> 
> //  PLLCFG  = (4 + (2 << 5));
> 
> 0x0000015E 4812 LDR R0,[PC,#0x048]  ; [0x1A8] =_A_PLLCFG (0xE01FC084)
> 0x00000160 2144 MOV R1,#68
> 0x00000162 6001 STR R1,[R0, #0]
> 
> My compiler has allocated a constant (address of PLLCFG) at 0x1A8 to
> avoid the limitation of the immediate operand size.  It looks like
> your compiler prefers code generation over the data allocation.  Not
> all compilers are made equal ;-)).
> 

When I optimize for size this is what CrossWorks generates.

Thanks,

Brian
-- 
-----------------------------------------------------
Brian C. Lane (W7BCL)                      Programmer
www.shinemicro.com   RF, DSP & Microcontroller Design

Peter wrote:

> The differences between MOV and LDR are:
> 
> MOV is for moving data between registers, or moving a constant
> encoded into the instruction into a register.
> 
> LDR is a memory-access instruction that loads a value from memory
> into a register.
> 

Ah! That makes sense. For some reason my reading of the opcodes hadn't 
made that distinction clear (or my recent use of the MSP430 corrupted my 
understanding).

> The second operand of a MOV may be shifted or rotated by a number of
> bits encoded into the instruction, or specified by the bottom byte of
> another register. The shift is carried out by dedicated hardware
> inline with the Op2 input into the ALU, so it has zero time overhead,
> unless of course the shift amount is specified in another register -
> in the ARM7 there are just two register read ports, so the processor
> stalls for one cycle while the shift amount is read from the register.
> 
> The shift/rotate hardware is used when extracting a constant encoded
> into a dataprocessing instruction (ADD, SUB, CMP, MOV etc). The
> encoding is "8 bits, optionally rotated right by an even number of
> bits" - so 8 bits anywhere in the 32-bit word isn't strictly accurate.
> 
> In the ARM assembler, a useful syntactical nicety is:
>      MOV Rd,=0xfeedbeef
> The assembler will turn this into a MOV or MVN if at all possible,
> otherwise it will create a literal pool entry and a pc-relative LDR
> instruction.
> 
> The only mildly reasonable argument for using three instructions to
> construct a constant rather than a pc-relative load from a literal
> pool, is that in a cached system it may turn out that the pc-relative
> load forces a cache-line eviction and reload... but that's not a very
> convincing argument to me.

I suspected it might be a pipeline thing, since I still don't have a 
good handle on how all these bits fit together. I'm using a LPC2138 so 
it has a 3 level pipeline and Memory Accelerator.

Thanks,

Brian

-- 
-----------------------------------------------------
Brian C. Lane (W7BCL)                      Programmer
www.shinemicro.com   RF, DSP & Microcontroller Design

Something is odd here. I can't think of a reason why the address is loaded 
with 3 instructions. One optimization we are considering is to cache the 
base address in a register, but this is not it. In either ARM or Thumb 
mode, the shortest sequence is something like this:
         mov R0,#68
         ldr R1,LIT_main+0
         str R0,[R1,#0]

Pipelining doesn't do anything in this regard. Using 3 instructions instead 
one in the same processor with sane instruction cycles is never going to be 
a win :-)

At 12:59 PM 8/26/2005, you wrote:

>y4krys wrote:
>
> > Brian,
> > This is how it looks compiled with my tools in the THUMB mode:
> >
> > //  PLLCFG  = (4 + (2 << 5));
> >
> > 0x0000015E 4812 LDR R0,[PC,#0x048]  ; [0x1A8] =_A_PLLCFG (0xE01FC084)
> > 0x00000160 2144 MOV R1,#68
> > 0x00000162 6001 STR R1,[R0, #0]
> >
> > My compiler has allocated a constant (address of PLLCFG) at 0x1A8 to
> > avoid the limitation of the immediate operand size.  It looks like
> > your compiler prefers code generation over the data allocation.  Not
> > all compilers are made equal ;-)).
> >
>
>When I optimize for size this is what CrossWorks generates.
>
>Thanks,
>
>Brian
>--
>-----------------------------------------------------
>Brian C. Lane (W7BCL)                      Programmer
>www.shinemicro.com   RF, DSP & Microcontroller Design
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>

// richard (This email is for mailing lists. To reach me directly, please 
use richard at imagecraft.com)

On Saturday 27 August 2005 00:46, y4krys wrote:
> What is the mode your compiler is set to?  In THUMB mode all data
> must be 16 bits long.  ARM can add shifts to load some 32-bit values
> to registers, but not always.

There is an often-spouted fallacy that Thumb mode is like x86 16-bit mode with 
16-bit data/registers. This is not so.

Thumb is only a 16-bit encoding of a subset of the the ARM instructions. The 
Thumb instructions are effectively decoded in hardware (no overhead) to 
generate an underlying ARM instruction.

Thumb instructions still process data as 32-bit entities using 32-bit 
registers, using 32-bit literal pools etc.

The only difference as far as data handling is concerned is that Thumb has a 
reduced number of bits, so the values handled by mov immediate instructions 
is limited.

> The ARM-ARM is published by Addison-Wesley, and ARM does not
> seem to post a copy of it on their web site, however, the
> other day I stumbled across it on Altera's web site ...

I have not found a second edition of the ARM ARM PDF on any web site.
Please let me know if anyone knows a URL where it might be.

Eric

> 
> > The ARM-ARM is published by Addison-Wesley, and ARM does not
> > seem to post a copy of it on their web site, however, the
> > other day I stumbled across it on Altera's web site ...
> 
> I have not found a second edition of the ARM ARM PDF on any web site.
> Please let me know if anyone knows a URL where it might be.

Hi Eric,

I've just received the ARM technical publications CD, and 
the ARM-ARM is not on there either - so I guess they want
you to purchase the book from now on.

Dave

I just received a copy of the second edition, ordered off amazon.  
It appears to be identical to the pdf from one of the links posted a 
week or so ago.  The book only covers through the arm5 variants.

--- In lpc2000@yahoogroups.com, "David Hawkins" <dwh@o...> wrote:
> 
> 
> > 
> > > The ARM-ARM is published by Addison-Wesley, and ARM does not
> > > seem to post a copy of it on their web site, however, the
> > > other day I stumbled across it on Altera's web site ...
> > 
> > I have not found a second edition of the ARM ARM PDF on any web 
site.

> > Please let me know if anyone knows a URL where it might be.
> 
> Hi Eric,
> 
> I've just received the ARM technical publications CD, and 
> the ARM-ARM is not on there either - so I guess they want
> you to purchase the book from now on.
> 
> Dave

--- In lpc2000@yahoogroups.com, "bell_c_d" <bell_c_d@y...> wrote:
> I just received a copy of the second edition, ordered off amazon.  
> It appears to be identical to the pdf from one of the links posted a 
> week or so ago.  The book only covers through the arm5 variants.

Its my understanding that the second edition covers the Thumb
instruction set, but the first edition did not. Is this true?

Or, were the Thumb instructions added after the arm5?

At 10:53 PM 9/2/2005, Eric Engler wrote:
>--- In lpc2000@yahoogroups.com, "bell_c_d" <bell_c_d@y...> wrote:
> > I just received a copy of the second edition, ordered off amazon.
> > It appears to be identical to the pdf from one of the links posted a
> > week or so ago.  The book only covers through the arm5 variants.
>
>Its my understanding that the second edition covers the Thumb
>instruction set, but the first edition did not. Is this true?

My copy of the ARM ARM pdf (ARM DD1 0100E, from an ARM developer's cd) is 
marked June 2000, Issue E, "Updated for ARM architecture v5TE and 
corrections to Part B.".

It does cover the Thumb instructions.


--
newell

> At 10:53 PM 9/2/2005, Eric Engler wrote:
> >--- In lpc2000@yahoogroups.com, "bell_c_d" <bell_c_d@y...> wrote:
> > > I just received a copy of the second edition, ordered off amazon.
> > > It appears to be identical to the pdf from one of the links posted a
> > > week or so ago.  The book only covers through the arm5 variants.
> >
> >Its my understanding that the second edition covers the Thumb
> >instruction set, but the first edition did not. Is this true?
>
> My copy of the ARM ARM pdf (ARM DD1 0100E, from an ARM developer's cd) is
> marked June 2000, Issue E, "Updated for ARM architecture v5TE and
> corrections to Part B.".
>
> It does cover the Thumb instructions.

The link to the PDF I posted is the same as the ARM-ARM book
by Seal (2nd Edition).

Dave