Georg-Johann Lay wrote:
David Brown schrieb:
Georg-Johann Lay wrote:
regardless if optimization is on or not. If fact I would guess that
it is a policy that the code *must* be the same regardless what debug
level (if any) or debug format is used, and code beeing dependent on
debug
Vincent Trouilliez schrieb:
On Sat, 28 Feb 2009 19:09:13 -0700
Weddington, Eric ewedding...@cso.atmel.com wrote:
So in application code I tend to avoid switch statements for embedded systems,
unless I'm writing throw-away code or the application is trivial.
Oh no ! ;-)
I have only recently
And the first complies with coding standards like gnu and gcc,
and maybe even others like misra etc.
MISRA doesn't say a lot about style, that is how pretty
the code looks. It is implicit that ugly looking code
is bad, and probably buggy. If your code looks
like a IOCCC entry, your code would
Vincent Trouilliez wrote:
On Sat, 28 Feb 2009 19:24:38 -0700 Weddington, Eric
ewedding...@cso.atmel.com wrote:
You wouldn't need *nested* ifs, but an if-else-if structure, or
better yet, a table of function pointers, also known as a dispatch
table. Each method depends on the type of data that
Thanks all for the input on switch statement, I appreciate.
On Sun, 01 Mar 2009 14:37:57 +0100
David Brown david.br...@hesbynett.no wrote:
Apart from that, I've a couple of other comments on your code. The
variable names tmp16, tmp32 and tmpS16 are truly awful.
Oh :-) I was just trying to
David Brown schrieb:
variable names tmp16, tmp32 and tmpS16 are truly awful. It is
also (usually) best to declare such temporaries in as small a block as
possible. Thus they should not be at the start of the function, but
instead make your cases like this:
{// (N * 0.75) - 40DB41
-Original Message-
From:
avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org
[mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.
org] On Behalf Of Bob Paddock
Sent: Sunday, March 01, 2009 6:22 AM
To: avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Re: C vs
Vincent Trouilliez wrote:
Thanks all for the input on switch statement, I appreciate.
On Sun, 01 Mar 2009 14:37:57 +0100
David Brown david.br...@hesbynett.no wrote:
Apart from that, I've a couple of other comments on your code. The
variable names tmp16, tmp32 and tmpS16 are truly awful.
Georg-Johann Lay wrote:
David Brown schrieb:
variable names tmp16, tmp32 and tmpS16 are truly awful. It is
also (usually) best to declare such temporaries in as small a block as
possible. Thus they should not be at the start of the function, but
instead make your cases like this:
{// (N *
-Original Message-
From: Bob Paddock [mailto:bob.padd...@gmail.com]
Sent: Sunday, March 01, 2009 9:59 AM
To: Weddington, Eric
Cc: avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Re: C vs. assembly performance
Would be nice. There are probably legal issues with doing
David Brown schrieb:
Georg-Johann Lay wrote:
Source code structure is a concern of the project, not of the compiler.
Even for braindead code that comes from a code generator a compiler is
supposed to yield good results.
That's true in theory - but embedded programmers are used to the
Would be nice. There are probably legal issues with doing that.
MISRA is one of those things you must buy. There are not Open Source
versions, as MISRA does not allow the distribution of the
rules without proper licensing.
I wasn't aware of that. How disgusting.
Yes. Standards are
Georg-Johann Lay wrote:
David Brown schrieb:
Georg-Johann Lay wrote:
As far as the optimizer of gcc is concerned, that makes no
difference. It knows exactly what register contains what value and
is aware of the place where a register dies, i.e. the register can
be reused for whatever
David Brown schrieb:
Georg-Johann Lay wrote:
regardless if optimization is on or not. If fact I would guess that it
is a policy that the code *must* be the same regardless what debug
level (if any) or debug format is used, and code beeing dependent on
debug level/format is worth a bug report.
David Brown schrieb:
I haven't looked at code generated for such switches (there is often so
much of it), so I admit to having guessed a little. I was thinking
especially of when you have debug information enabled - that can force
the compiler to keep variables in separate registers.
If I wanted fast and small, I'd have done it in ASM. But half of the point
of this exercise was to get my feet wet with C.
So, both points accomplished. I have GCC up under AVR studio, a working
project, and I feel reasonably confident with the code.
Despite avr-gcc being fairly dim about
From: Nicholas Vinen h...@x256.org
For example, things like unsigned char x, y;
x = y4 could
use the nibble swap instruction rather than four shifts,
and things like
Shifting a byte or int right or left must push in 00s from the other side so
swapping a nibble is not the right thing to
Nicholas Vinen schrieb:
* On the other hand, it would be great if avr-gcc could perform some
basic optimisations that even a fairly inexperienced amateur could
manage. For example, things like unsigned char x, y; x = y4 could
use the nibble swap instruction rather than four shifts, and things
Parthasaradhi Nayani wrote:
From: Nicholas Vinen h...@x256.org
For example, things like unsigned char x, y;
x = y4 could
use the nibble swap instruction rather than four shifts,
and things like
Shifting a byte or int right or left must push in 00s from the other side
Georg-Johann Lay wrote:
compiling the following code
unsigned char sh4 (unsigned char x)
{
return x 4;
}
unsigned char sh8 (unsigned short x)
{
return x 8;
}
with avr-gcc 4.3.2 and -Os yields (non-code stripped)
sh4:
swap r24 ;
andi r24,lo8(15) ; ,
Georg-Johann Lay wrote:
If you are sure it is really some performance issue/regression and not
due to some language standard implication, you can add a report to
http://sourceforge.net/tracker/?group_id=68108
so that the subject won't be forgotten. Also mind
Subject: Re: [avr-gcc-list] Re: C vs. assembly performance
Now that I've signed up to this list, if and when I come
across avr-gcc missing obvious optimisations I'll report them.
We certainly appreciate bug reports. However, before you report them, please
make sure that they haven't been
Nicholas Vinen schrieb:
Georg-Johann Lay wrote:
If you are sure it is really some performance issue/regression and not
due to some language standard implication, you can add a report to
http://sourceforge.net/tracker/?group_id=68108
so that the subject won't be forgotten. Also mind
Subject: Re: [avr-gcc-list] Re: C vs. assembly performance
Note that this may partially be covered by report 145284
(which I cannot
find, maybe Eric has closed/removed it)
I'm sorry, but on which project?
___
AVR-GCC-list mailing list
AVR-GCC-list
-list@nongnu.org
Subject: Re: [avr-gcc-list] Re: C vs. assembly performance
Note that this may partially be covered by report 145284
(which I cannot
find, maybe Eric has closed/removed it)
Sorry, my mistake. I wrote the patch because I saw gcc 4 making bad code
(campared with 3.4.6) and read
-Original Message-
From: Georg-Johann Lay [mailto:a...@gjlay.de]
Sent: Saturday, February 28, 2009 10:09 AM
To: Weddington, Eric
Cc: Nicholas Vinen; avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Re: C vs. assembly performance
Weddington, Eric schrieb:
BTW
Nicholas Vinen wrote:
OK, I only spent a few minutes looking at old code and I found some
obviously sub-optimal results. It distills down to this:
#include avr/io.h
int main(void) {
unsigned long packet = 0;
while(1) {
if( !(PINC _BV(PC2)) ) {
packet = (packet1)|(((unsigned
David Brown schrieb:
Nicholas Vinen wrote:
OK, I only spent a few minutes looking at old code and I found some
obviously sub-optimal results. It distills down to this:
#include avr/io.h
int main(void) {
unsigned long packet = 0;
while(1) {
if( !(PINC _BV(PC2)) ) {
packet =
-Original Message-
From:
avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org
[mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.
org] On Behalf Of Bob Paddock
Sent: Saturday, February 28, 2009 6:40 PM
To: avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Re
On Sat, 28 Feb 2009 19:09:13 -0700
Weddington, Eric ewedding...@cso.atmel.com wrote:
So in application code I tend to avoid switch statements for embedded
systems, unless I'm writing throw-away code or the application is trivial.
Oh no ! ;-)
I have only recently got round to using switch
-list] Re: C vs. assembly performance
On Sat, 28 Feb 2009 19:09:13 -0700
Weddington, Eric ewedding...@cso.atmel.com wrote:
So in application code I tend to avoid switch statements
for embedded systems, unless I'm writing throw-away code or
the application is trivial.
Oh no ! ;-)
I have
On Sat, 28 Feb 2009 19:24:38 -0700
Weddington, Eric ewedding...@cso.atmel.com wrote:
You wouldn't need *nested* ifs, but an if-else-if structure, or better yet, a
table of function pointers, also known as a dispatch table. Each method
depends on the type of data that you're switching on.
I
-list] Re: C vs. assembly performance
I switch on an unsigned byte, with contiguous values (0-24).
A Function table sounds elegant to my ear, but it would mean 25
functions ! In my case the work is done in-situ, within the switch
statement, as it's takes only 2 or 3 statements to process
33 matches
Mail list logo
