Lpc2000

\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd \ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd wrote:
>>Alex, 
>>
>>
>>>b> Just one data point, but: I'm a professional developer (30 
>>>years s/w 
>>>b> development experience from micros to mainframes).  Now working 
>>>on 
>>>b> third LPC-based commercial product.  Compared Keil, IAR, 
>>>and gcc and 
>>>b> chose Rowley Crossworks (gcc-based).
>>>
>>>Oh, I can't hold out from the reply.
>>>I tried to use Crossworks in the begining to explore LPC2xxx.
>>>It ugly work with the structures. I tried to define T0MCR like
>>> struct:
>>>{{
>>>typedef struct
>>>  { 
>>>    __REG32 MR0I :1;
>>>    __REG32 MR0R :1;
>>>    __REG32 MR0S :1;
>>>
>>>    __REG32 MR1I :1;
>>>    __REG32 MR1R :1;
>>>    __REG32 MR1S :1;
>>>    
>>>    __REG32 MR2I :1;
>>>    __REG32 MR2R :1;
>>>    __REG32 MR2S :1;
>>>    
>>>    __REG32 MR3I :1;
>>>    __REG32 MR3R :1;
>>>    __REG32 MR3S :1;    
>>>    __REG32      :4;    
>>>} __txmcr_bits;
>>>
>>>#define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)
>>>
>>>}}
>>>
>>>but when I handle to it, Crossworks GCC compile it to this code:
>>>
>>><<T0MCRbits.MR0I = 1;>>
>>>
>>>mov r3, #0xE0000000
>>>add r3, r3, #0x00004000
>>>add r3, r3, #0x00000014
>>>ldrb r2, [r3]
>>>orr r2, r2, #0x00000001
>>>strb r2, [r3]
>>>
>>>so, I get change in LSB and _in_the_second_byte_!.
>>
>>And you tell me *why* this is incorrect code generation?  You might 
>>not
>>like what is generated, but is is *not* incorrect according to the
>>standard.  It is only incorrect *if* you think volatile has some 
>>extra
>>meaning above what it does in the standard.  Or *if* you think an
>>"unsigned long" bitfield is somehow "standard".  That is why the
>>Embedded C TR has I/O support.  Volatile does *not* mean "I'm 
>>dealing
>>with a device" or "Access this data atomically".  Far from it.
> 
> 
> I tried to explain my point of view in other mail.
> The generated code works incorrectly because it use BYTE instructions. 
> You can compile it, load into the chip and debug. We discuss compiler 
> for ARM core, or what? I think IAR, Keil compilers know about data 
> access in the ARM core.
> 

This behaviour is not bug, it's really a feature. GCC is optimizing the
accesss to this bit-field to a minimum. Loading and storing only _one_
byte for modifing only _one_ bit is a very good optimization on designs
with external memory, which is not 32bit wide, to minimize memory access
cycles. GCC doesn't know that a certain register _must_ be accessed with
32bit (with or without "volatile") and C standard does not say that a
bit field manipulation is forced to be a 16bit or 32bit access. What
should happen, in your opinion, if you declare a bit field with more
than 32 bit??? How should it be handled?
With other words: Compiler which are using a 32bit access for such a bit
field manipulation lacks an optimization feature!!!

  Sten

-- 
/************************************************
 Do you need a tiny and efficient real time
 operating system (RTOS) with a preemtive
 multitasking for LPC2000 or AT91SAM7?

   http://nanortos.net-attack.de/

 Or some open-source tools and code for LPC2000?

   http://www.net-attack.de/

************************************************/