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. 

So what?  It might not be what you want, but it is not incorrect
according to the ISO standard.

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

Sure, GCC knows about alignment.  But you are now using bitfields which
are a completely different kettle of fish and mixing in volatile to try
to do something which is not possible to describe in *standard* ANSI C.
If you can point me to a paragraph or clause in the ISO standard that
says my interpretetation is incorrect or yours is correct that's good,
we can make some progress.  Supposition isn't any use.  As I said, the
generated code might be as useful as a box of chocolate frogs and seen
to be incorrect from one viewpoint, but it does not violate the ANSI/ISO
standard, so is correct from another viewpoint.

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

Sure, I understand about the compiler.  That might change.

-- Paul.