Reply by FreeRTOS Info●September 20, 20112011-09-20
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
>
>
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
Reply by Paul Curtis●September 20, 20112011-09-20
> 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.
Reply by Jean-Jacques Dauchot●September 20, 20112011-09-20
> Are you sure it is not done to make it difficult to
port away from their
> compiler?
IAR is very good at doing this.
Have you ever tried porting IAR Demo code to say GCC etc.
Its practically impossible.
Regards
Jean-Jacques
--- In l..., FreeRTOS Info wrote: > On 20/09/2011 16:35, Tim Mitchell wrote:
> >
> >
> > ----Original Message----
> > From: l...
> > [mailto:l... ] On
> > Behalf Of Paul Curtis
> > Sent: 20 September 2011 16:23 To: l...
> >
> > Subject: RE: [lpc2000] strange casting in Keil compiler
> >
> >> I fail to see why code such as this would ever be
> >> necessary. If you cast,
> >> as you have, the meaning is 100% clear. As you are
> >> already uncertain of
> >> what the original code does, WHY WOULD YOU SEEK TO KEEP
> >> IT?
> >
> > I don't want to keep it - I'm just trying to get the (usb) demo
code to
> > compile... and there's quite a lot of lvalue-casting going on in
there.
> > As far as I can see they do this to reuse a pointer of the wrong type to
> > point to a different type of variable.
>
> Are you sure it is not done to make it difficult to port away from their
> compiler?
> Regards,
> Richard.
>
> + http://www.FreeRTOS.org
> Designed for Microcontrollers.
> More than 7000 downloads per month.
>
Reply by Tim Mitchell●September 20, 20112011-09-20
----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
Reply by Phil Young●September 20, 20112011-09-20
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.
The best thing to do if you want to access the structure contents as bytes
is make a local copy as a byte pointer.
e.g. uint8_t * pData = (uint8_t *) p;
now pData++ will work fine, p can then be discarded.
Obviously p has to be a local pointer which is discarded anyway for the
reason given above.
Regards
Phil.
From: l... [mailto:l...] On Behalf Of
Tim Mitchell
Sent: 20 September 2011 16:36
To: l...
Subject: RE: [lpc2000] strange casting in Keil compiler
----Original Message----
From: l...
[mailto:l... ] On
Behalf Of Paul Curtis
Sent: 20 September 2011 16:23 To: l...
Subject: RE: [lpc2000] strange casting in Keil compiler
> I fail to see why code such as this would ever be
> necessary. If you cast,
> as you have, the meaning is 100% clear. As you are
> already uncertain of
> what the original code does, WHY WOULD YOU SEEK TO KEEP
> IT?
I don't want to keep it - I'm just trying to get the (usb) demo code
to
compile... and there's quite a lot of lvalue-casting going on in there.
As far as I can see they do this to reuse a pointer of the wrong type to
point to a different type of variable.
--
Tim Mitchell
Reply by FreeRTOS Info●September 20, 20112011-09-20
On 20/09/2011 16:35, Tim Mitchell wrote: >
>
> ----Original Message----
> From: l...
> [mailto:l... ] On
> Behalf Of Paul Curtis
> Sent: 20 September 2011 16:23 To: l...
>
> Subject: RE: [lpc2000] strange casting in Keil compiler
>
>> I fail to see why code such as this would ever be
>> necessary. If you cast,
>> as you have, the meaning is 100% clear. As you are
>> already uncertain of
>> what the original code does, WHY WOULD YOU SEEK TO KEEP
>> IT?
>
> I don't want to keep it - I'm just trying to get the (usb) demo code
to
> compile... and there's quite a lot of lvalue-casting going on in
there.
> As far as I can see they do this to reuse a pointer of the wrong type to
> point to a different type of variable.
Are you sure it is not done to make it difficult to port away from their
compiler?
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.
Reply by "Gromann, Klaus"●September 20, 20112011-09-20
Hi Tim,
This code makes no sense. Are you sure that it isn't
*(uint8_t *)p++ = some addition;
The line above is also a terrible code but it should compile.
--
Klaus Gromann
I'm trying to port some NXP demo code to Rowley Crossworks, it's
written for Keil and has a cast on the left hand side of an addition.
The Keil code has
paramstruct *p;
(uint8_t *)p++;
p is a pointer to a struct 4 bytes long. I presume this is meant to advance the
pointer 1 byte.
Crossworks won't compile this - "lvalue required as left operand of
assignment"
The best I can come up with that will compile without warnings is
p = (paramstruct *)((uint8_t *)p+1);
-which is a bit horrible - is there a good way to do this?
--
Tim Mitchell
________________________________
Sample disclaimer text
Reply by Phil Young●September 20, 20112011-09-20
It looks like this is ambiguous, when the cast is actually applied.
Are you trying to cast the result of the post increment operator, or cast p
as a pointer before incrementing it.
The code as it is written would perform a post increment of p, so it is
casting p with no assignment to anything
Try ((uint8_t *)p)++;
Regards
Phil.
From: l... [mailto:l...] On Behalf Of
Paul Curtis
Sent: 20 September 2011 16:23
To: l...
Subject: RE: [lpc2000] strange casting in Keil compiler
> I'm trying to port some NXP demo code to Rowley
Crossworks, it's
> written for Keil and has a cast on the left hand side of an addition.
>
> The Keil code has
> paramstruct *p;
>
> (uint8_t *)p++;
>
> p is a pointer to a struct 4 bytes long. I presume this is meant to
> advance the pointer 1 byte.
>
> Crossworks won't compile this - "lvalue required as left operand of
> assignment"
>
> The best I can come up with that will compile without warnings is p >
(paramstruct *)((uint8_t *)p+1);
>
> -which is a bit horrible - is there a good way to do this?
The original is a bit horrible because it's non-standard. A cast is
always
an r-value, never an l-value. Code such as that should never, ever compile,
not be seen in polite company.
I fail to see why code such as this would ever be necessary. If you cast,
as you have, the meaning is 100% clear. As you are already uncertain of
what the original code does, WHY WOULD YOU SEEK TO KEEP IT?
> ----Original Message----
> From: l...
> [mailto:l...] On Behalf Of Paul Curtis
> Sent: 20 September 2011 16:23 To: l...
> Subject: RE: [lpc2000] strange casting in Keil compiler
>
> > I fail to see why code such as this would ever be necessary. If you
> > cast, as you have, the meaning is 100% clear. As you are already
> > uncertain of what the original code does, WHY WOULD YOU SEEK TO KEEP
> > IT?
>
> I don't want to keep it - I'm just trying to get the (usb) demo code
to
> compile... and there's quite a lot of lvalue-casting going on in
there.
> As far as I can see they do this to reuse a pointer of the wrong type
> to point to a different type of variable.
Ok, shame on the author. Nightmare. :-( One assumes that 'volatile'
may
also be a problem if this type of error is already present in the code. Oh
well.
