> Actually, this is Very dangerous code, casting a pointer to a different
> type then incrementing it will corrupt the pointer, it would no longer
> have the correct alignment and any further use of the pointer in its
> original form could generate an unaligned load / store which will cause
> a hard fault.

It's even more dangerous with a highly optimizing compiler which takes every
latitude possible to make code small and fast, which is what user crave.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426

Start a New Thread

Strange that, but NXP actively promote the LPCXpresso boards with demo's
which are GNU / Eclipse.

Personally I moved to Keil because the Code Red tools generate much less
efficient code, it was far too big and just compiling with Keil reduced it
massively.

Not necessarily the compilers fault, more to do with how the GNU linker
works I think.

BTW, the Keil compiler is the same compiler as used in RVDS, simply
restricted on what processor it supports ( Keil is part of ARM now ).

Cheers

Phil.

From: l... [mailto:l...] On Behalf Of
Tim Mitchell
Sent: 20 September 2011 16:58
To: l...
Subject: RE: [lpc2000] strange casting in Keil compiler

----Original Message----
From: l...
[mailto:l... ] On
Behalf Of FreeRTOS Info
Sent: 20 September 2011 16:54 To: l...

Subject: Re: [lpc2000] strange casting in Keil compiler

> Are you sure it is not done to make it difficult to port
> away from their
> compiler?

It probably is. Unfortunately all NXP's demo code is written for Keil tools.

--
Tim Mitchell



Start a New Thread

On 20/09/2011 20:04, Phil Young wrote:
>
>
> Strange that, but NXP actively promote the LPCXpresso boards with demo's
> which are GNU / Eclipse.
>
> Personally I moved to Keil because the Code Red tools generate much less
> efficient code, it was far too big and just compiling with Keil reduced it
> massively.
>
> Not necessarily the compilers fault, more to do with how the GNU linker
> works I think.
>
> BTW, the Keil compiler is the same compiler as used in RVDS, simply
> restricted on what processor it supports ( Keil is part of ARM now ).
I don't like to get drawn into conversations about the various merits of
different compilers - I use and support them all. Deliberately without
making a comparison - I do think though, that with some knowledge and
persistence, GCC can be made to behave better than its "out of the box"
configuration. For example, you can use the -ffunction-sections and
-fdata-section compiler and -[whatever it is] linker option to ask it
nicely to remove unused code and thereby reduce your binary size
massively (if somewhat crudely). Other compilers, by comparison, will
just do it by default without you having to ask.

The real gotcha with GCC is the libraries though. They can be hideous
on a small microcontroller. That is why people like Rowley
differentiate their products with highly tuned libraries. Code Red
provide NewLib (yuk) and RedLib options, etc. Even FreeRTOS ships with
an ultra light sprintf()/etc. implementation that, just by including it
in a GCC project, can massively cut down your binary image size. If you
are not careful, using a GCC sprintf() like function in will drag in
lots of floating point and malloc() functionality your binary image just
doesn't need.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.

>
> Cheers
>
> Phil.
>
> From: l...
> [mailto:l... ] On
> Behalf Of
> Tim Mitchell
> Sent: 20 September 2011 16:58
> To: l...
> Subject: RE: [lpc2000] strange casting in Keil compiler
>
> ----Original Message----
> From: l...
>
> [mailto:l...
> ] On
> Behalf Of FreeRTOS Info
> Sent: 20 September 2011 16:54 To: l...
>
>
> Subject: Re: [lpc2000] strange casting in Keil compiler
>
>> Are you sure it is not done to make it difficult to port
>> away from their
>> compiler?
>
> It probably is. Unfortunately all NXP's demo code is written for Keil tools.
>
> --
> Tim Mitchell
>
>

Start a New Thread