[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] Re: C vs. assembly performance
From: |
Vincent Trouilliez |
Subject: |
Re: [avr-gcc-list] Re: C vs. assembly performance |
Date: |
Sun, 1 Mar 2009 15:15:57 +0100 |
Thanks all for the input on switch statement, I appreciate.
On Sun, 01 Mar 2009 14:37:57 +0100
David Brown <address@hidden> 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 give their meaningful names.
They are just that: temporary/scratch integers used only to
process the raw data byte before it can be sent to the function
var_format_S16() which will convert it to ASCII.
> 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) - 40 DB41 -40 to +150 °C
> int16_t temp = (int16_t)(KLineFrameM1[41]) * 3 / 4 - 40;
> var_format_S16(buff, temp, 0);
> break;
> }
>
Hmm, actually I didn't even know one could declare local variables
inanother place than the start of the function, I take note.
> That will give clearer code
I find it just adds bloat and confusion: I have to declare the variable
25 times every 5 lines of code, that's overwheleming, plus it make the
statement harder to parse (my brain is easily overloaded ;-), and also,
it is a little confusing/harder to understand: if the variable is
declared 25 times, one could think: "well if it's a diffeent variable
everytime, there must be something special/obscure that makes it
impossible to use the same temp/scratch integer. This leaves a false
impression that the processing of the 25 individual data bytes is more
complex than it really is, and that a single temp integer could
perfectly be used.
Well that's just my view as a beginner.. maybe with time I will
progressively start to see things the way you do ! ;-)
> Also avoid local automatic constant arrays (like "Yes" in your example)
Yes I don't like them, but since they just that, "local", I didn't want
to declare them global, to avoid throwing bloat and confusion among all
the variables declaration which are truly/genuinely global.
> - they must be built on the stack each time the function is called,
> whether they are used or not.
Yes, I was conscious of this but it was trade-off between wasting time
initialising them each time I enter the function.. and degrading code
clarity by defining local variables among truly global ones. Doesn't
make me happy.. like most compromises I suppose ! ;-)
> By making these "static", they will have
> local names but be built once at the start of the program.
He ? Wow, so I can get the best of both worlds, just be qualifying them
"static" ?! Yahoo !!!!! :o)
Thanks David, you just made me and my code that little bit better ! :-)
> If you are short on ram space, you might also want to make them PROGMEM.
Yeah I do do this at times, even though I have ample available RAM..
just because I don't like wasting things, be it MCU resources or money
or anything, it's just a general state of mind ;-)
The "Yes" and "No" strings I accepted to waste RAM on because they are
very short. But other strings in the program, which are 20 characters
long and used in several times, I declared them global to save memory.
Thanks for you comment, made my program better and I, a little bit
smarter/skilled ;-)
--
Vince
- [avr-gcc-list] Re: C vs. assembly performance, David Brown, 2009/03/01
- Re: [avr-gcc-list] Re: C vs. assembly performance,
Vincent Trouilliez <=
- Re: [avr-gcc-list] Re: C vs. assembly performance, Georg-Johann Lay, 2009/03/01
- [avr-gcc-list] Re: C vs. assembly performance, David Brown, 2009/03/01
- Re: [avr-gcc-list] Re: C vs. assembly performance, Georg-Johann Lay, 2009/03/01
- [avr-gcc-list] Re: C vs. assembly performance, David Brown, 2009/03/01
- Re: [avr-gcc-list] Re: C vs. assembly performance, Georg-Johann Lay, 2009/03/01
- [avr-gcc-list] Re: C vs. assembly performance, David Brown, 2009/03/02
- Re: [avr-gcc-list] Re: C vs. assembly performance, Georg-Johann Lay, 2009/03/01
RE: [avr-gcc-list] Re: C vs. assembly performance, Weddington, Eric, 2009/03/01
Re: [avr-gcc-list] Re: C vs. assembly performance, Georg-Johann Lay, 2009/03/01