| Author |
Message |
|
|
 Posted: Jun 08, 2012 - 12:13 PM |
|
Joined: Apr 05, 2012
Posts: 23
Location: New Zealand
|
|
First off, i have no idea if this forum is about gcc development or just gcc questions, so bear with me if i'm posting this in the wrong forum.
I was wondering if i were to write
Code:
int var = 120 / 2;
This is obviously always going to evaluate to the same number, 60, but will the compiler recognize it and rather than making the AVR waste processing time and calculate it in code, will it just initialize it to 60.
Also, does this apply to all versions of gcc? Like the gcc that runs Linux or the version that runs on Windows?
- Dylan |
|
|
| |
|
|
|
|
|
|
Posted: Jun 08, 2012 - 12:32 PM |
|
Joined: Feb 12, 2005
Posts: 16279
Location: Wormshill, England
|
|
I think that even the first C compiler would evaluate the constant expression.
Nowadays, compilers are pretty clever. I suggest that you do not worry about how or what they do. Just write straightforward code and let the compiler sort it out.
There are many 'advisory' articles on selecting the appropriate size of a variable. The AVR is 8-bit so use unsigned 8-bit when you can. 16-bit, 32-bit, floats etc only when necessary.
Learn when to use 'volatile' or 'const' qualifiers. Get this right for GCC because it will aggressively optimise any variable that it can. Other compilers may not be so fierce now, but one day they will follow GCC.
David. |
|
|
| |
|
|
|
|
|
|
Posted: Jun 08, 2012 - 12:40 PM |
|
Joined: Apr 05, 2012
Posts: 23
Location: New Zealand
|
|
On a side note, i'm quite sure that the C specification states that "int" will always be signed unless stated explicitly, but does this also apply to the avr world.
In my for loops, i just use
for(int i=0; i<(blah blah); i++)
;
(Thank you C99  )
I know that i should use unsigned int or uint8_t depending on the situation, and that signed math can be a lot slower than unsigned math. So is int in avr a signed integer.
And also is in 8 bits wide as the architecture would suggest?
- Dylan |
|
|
| |
|
|
|
|
|
|
Posted: Jun 08, 2012 - 01:08 PM |
|
Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia
|
|
|
dylan45pie wrote:
This is obviously always going to evaluate to the same number, 60, but will the compiler recognize it and rather than making the AVR waste processing time and calculate it in code, will it just initialize it to 60.
While there are several optimization options (collected under the "crude" optimization switch -O), and while the compiler is free to do whatever it takes to arrive to the same result (including doing what appears to be nonsense), a quick test reveals that even with -O0 (i.e. no optimization) gcc simply loads 60 rather than run-time calculating the constant.
Generally, there is no guarantee for this, of course.
dylan45pie wrote:
Also, does this apply to all versions of gcc? Like the gcc that runs Linux or the version that runs on Windows?
If the same version of gcc (i.e. the same sources of gcc) are compiled using the same configuration options for both Win and Lin, the resulting compiler works in the same way.
However, there are many "but-s" and nuances, when it comes to the details of "the same version" and "the same configuration". gcc is a huge project with many many tiny but important details.
(Under gcc, here, I understand the whole compiler bundle, including the assembler and linker).
dylan45pie wrote:
I know that i should use unsigned int or uint8_t depending on the situation, and that signed math can be a lot slower than unsigned math. So is int in avr a signed integer.
Yes.
dylan45pie wrote:
And also is in 8 bits wide as the architecture would suggest?
Since 2nd edition of K&R, int is required to be at least 16-bit long, and that's why int in avr-gcc is by default 16-bit long signed.
However, there is a command-line switch, which could set avr-gcc to a non-standard 8-bit-int setting. This results in some programs to more optimal binary, but is largely not standard-compliant thus might result in surprising problems (e.g. when using various libraries).
JW |
|
|
| |
|
|
|
|
|
|
Posted: Jun 08, 2012 - 01:10 PM |
|
Joined: Jul 18, 2005
Posts: 62244
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
So is int in avr a signed integer.
Yes (it is in all C compilers) but why guess about this stuff - this is why God invented stdint.h so you use int16_t when you want it signed and uint16_t when you don't, you are also no longer left in any mystery about how wide the variable is, "int" says nothing about its width int16_t says everything about its width and the fact it will always hold -32768..+32767 |
_________________
|
| |
|
|
|
|
|
|
Posted: Jun 08, 2012 - 01:13 PM |
|
Joined: Feb 12, 2005
Posts: 16279
Location: Wormshill, England
|
|
I would guess that you have read the "usual advice" articles. There is no harm in reading them again.
Likewise the C spec will explain default types, operator precedence etc. K&R is your best textbook. It is well written and concise. Avoid the big C textbooks. They are only good for landfill.
Don't worry unduly about the compiler. If signed 32-bit is appropriate, use it. Likewise floats or doubles. Don't undergo contortions because signed may be slightly slower than unsigned.
Make sure that you get the algorithm design right. Nowadays compilers work perfectly. They will do exactly what the language specifies.
Incidentally, not all compilers do C99. GCC will understand C99, hence your for() loop syntax is ok.
Once your application is working you may want to improve the efficiency. Most apps' execution time only depends on about 5% of the code. There is little point in you spending effort on the other 95%.
All the same, the AVR will process faster than the PIC. Most apps are limited by the peripherals. AVR peripherals are equally good as the PIC peripherals.
David. |
|
|
| |
|
|
|
|
|
|
Posted: Jun 08, 2012 - 01:21 PM |
|
Joined: Apr 05, 2012
Posts: 23
Location: New Zealand
|
|
| Thanks for the advice i think i'll get a copy of K&R, that should set me straight. |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
