Lpc2000

On Tue, 8 Nov 2005 09:08:29 -0000
  "Paul Curtis" <plc@...> 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. 
> 
> So what?  It might not be what you want, but it is not incorrect
> according to the ISO standard.

We discuss not any abstract ISO C compiler, but 
_C_compiler_for_ARM_core.
So, do you agree, that my _C_code_ correct? My target is to set one 
bit in T0MCR.
I compile it, load, and I see, that _ASM_code_ set TWO BITS (in LBS, 
as I want, and in previous byte). And after that you convince me that 
_ASM_code_ right?
Please don't tell me about ISO, K&R and other, we discuss concrete 
realisation of compiler _for_ARM_core. You can spend a little time to 
check it. This code really set TWO bits. WHY, I answer anoter mail.
I think decision in check of struct absolute size. If it bigger than 
byte - use word ARM ASM instruction, else use byte ARM ASM 
instruction.

>> 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.
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> 
>