Lpc2000

--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@p...> wrote:
>
> All,
> 
> I have been trying to follow the issue of the code generation for 
> the typedef.  So, I tried it for setting 3 of the bits; the two 
> least significant and the most significant, ignoring the padding:
> 
>   27:main.c        **** 	T0MCRbits.MR0I = 1;
>   26 000c 0E32A0E3 		mov	r3, #-536870912
>   27 0010 013983E2 		add	r3, r3, #16384
>   28 0014 143083E2 		add	r3, r3, #20
>   29 0018 0020D3E5 		ldrb	r2, [r3, #0]
>   30 001c 012082E3 		orr	r2, r2, #1
>   31 0020 0020C3E5 		strb	r2, [r3, #0]
> 
>   28:main.c        **** 	T0MCRbits.MR0R = 1;
>   32              		.loc 1 28 0
>   33 0024 0E32A0E3 		mov	r3, #-536870912
>   34 0028 013983E2 		add	r3, r3, #16384
>   35 002c 143083E2 		add	r3, r3, #20
>   36 0030 0020D3E5 		ldrb	r2, [r3, #0]
>   37 0034 022082E3 		orr	r2, r2, #2
>   38 0038 0020C3E5 		strb	r2, [r3, #0]
> 
>   29:main.c        **** 	T0MCRbits.MR3S = 1;
>   39              		.loc 1 29 0
>   40 003c 0E32A0E3 		mov	r3, #-536870912
>   41 0040 013983E2 		add	r3, r3, #16384
>   42 0044 143083E2 		add	r3, r3, #20
>   43 0048 0120D3E5 		ldrb	r2, [r3, #1]
>   44 004c 082082E3 		orr	r2, r2, #8
>   45 0050 0120C3E5 		strb	r2, [r3, #1]
> 
> Since the typedef describes only 16 bits, setting MR3S results in 
> setting the 4th bit of the second byte.  Seems right to me.  It 
> doesn't appear, to me anyway, that packing comes into play here.
> 
> OK, I think I understand: the problem is that you can't use byte 
> access to a 32 bit hardware register even if it is memory mapped.  
> But, the compiler can't KNOW that a given address must be handled as 
> a 32 bit access, it has to be told.  I suppose if the compiler were 
> SPECIFIC to a given piece of hardware it would be possible to impart 
> that knowledge but it isn't.

You can use 8bit access to 32bit memory, but some registers don't like
it. The compiler only sees some memory in which registers are mapped.
The compiler need not to know about certain registers. It should only
"convert" C code to machine code with a maximum of efficiency.

> 
> The thing I don't understand is the address calculation.  I am 
> using -O0 so I understand it won't do much optimizing but, to me, 
> the 3 instructions used to load a register with a constant value 
> seems excessive.  It gets a little better with -O3 but still, the 
> address is a constant, why calculate it?

ARM instructions can only take 12bit of immediate operands with a bit
displacement. So it is not possible to load a full 32bit immediate
value into a core register directly, except that the value can
separated into a single 12bit value and a shift value. If you turn on
optimization GCC may use a trick to minimize cycles. Immediate values
are stored in memory in a location near (< 2^12) to this instruction.
Now GCC can load this "immediate" value out of memory relativ to its
program counter in one cycle for example.

     LDR R0, [PC, #+15]

> 
> Now, since the compiler writers are very bright folks and I am just 
> a user who has never read the standard (how come I have to pay for 
> it?), I assume they do this calculation for a reason.  Does anyone 
> know why?

Compiler guys are totaly crazy! ;-)

> 
> Thanks
> Richard
>


  Sten