Lpc2000

> 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.

>> OK, forget about structures.
>> But when I try to compile code with some IRQ, I found, that 
>> optimize level has affect on the code! The code works differ 
>> with optimize level 1 and optimize level 3!
>> After that I found that interrupt context keeped incorrectly. 
>> So I had to keep context by ASM macros.
> 
> In the next release of CrossWorks, we have a revamp of the way
> interrupts are handled across processors.  This will make working 
>with
> the device library very attractive.

It's good news.
Please understand, I like Crossworks IDE, it's the best IDE that I 
used. But compiler...

> --
> Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
> CrossWorks for MSP430, ARM, AVR and now MAXQ processors