Go Down

Topic: "optimizing compiler" (Read 13464 times) previous topic - next topic

westfw

Quote
I'm afraid I will need a little more hand-holding than "I think it's a mess, fix it".   All of my libraries follow a form that appears to be fairly identical to the rest of the libraries I've downloaded.

I haven't actually looked at your code to see if this was a problem in your case, but the general rule-of-thumb is that a .h file should never create any data or code, only DEFINE data or functions that are actually implemented in .c/.cpp/etc files.

For example.  THIS IS WRONG:
messages.h:
Code: [Select]
void AddWord(uint8_t got_word_id) {
  message_word_id[message_wordcount] = got_word_id;
  message_wordcount = min(message_wordcount+1,message_max);
}


This would be better:
messages.h:
Code: [Select]
extern void AddWord(uint8_t got_word_id);
messages.c:
Code: [Select]
void AddWord(uint8_t got_word_id) {
  message_word_id[message_wordcount] = got_word_id;
  message_wordcount = min(message_wordcount+1,message_max);
}

virtual1


I haven't actually looked at your code to see if this was a problem in your case, but the general rule-of-thumb is that a .h file should never create any data or code, only DEFINE data or functions that are actually implemented in .c/.cpp/etc files.


OK I think you were misunderstanding the purpose of those .h files.  Tha project is thousands of lines long (not including the libraries) and so to keep things sane I have broken it up into a dozen "modules"  (the code from your example I believe is from my messages.h module)   The purpose of those modules is to collect common functions together for separate viewing.  So if I need to work on some aspect of how the transmitter is controlled, I don't have to sift through a hundred functions trying to find the ones responsible for the transmitter.  I just switch to the transmitter.h file in the IDE.

I'm used to this form of development with other languages similar to visual basic.  And in those cases, you do indeed collect related functions into modules.  For them, if you want to work on the keydown transmitter function, it's MUCH easier to find it - you just open the Transmitter module, and find the Keydown function, from a list that's sorted for you, alphabetically.  IMHO arduino's IDE makes juggling a larger project a lot more difficult than it should.  Without my "module" design, I'd be forced to use search to find the function, and would have sever "tunnel vision" with respect to what other transmitter functions were available.

I was actually a bit surprised to see the IDE seems to understand what I'm trying to do, and when I open the cleverfox.ino, it automatically loads up all my other modules in separate tabs.  It's really slick that way.  There are too many of them to all fit across the menu bar, so it develops a dropdown menu on the right for easy selection.

Maybe .h isn't required.  I really haven't spent much time with that, I just see what I'm doing is working, and I go with it.  If you look at my .ino file, you'll notice that all that's in there are some comments, and about a dozen #include, for the modules.  Maybe those would be better named .cpp?  MORE than once I've made a backup copy of an .ino file in its folder and found that when I tried to compile it, the IDE vaccuumed it up into the sketch during compile and gave me dupicate definition errors, so I haven't been too game to see what other "helpful behaviors" it is ready to spring on me.  So if I find something that works, I tend to stick with it unless required otherwise.  Unfortunately, I'm sure this will lead to some non-standard practices.

Jantje


I haven't actually looked at your code to see if this was a problem in your case, but the general rule-of-thumb is that a .h file should never create any data or code, only DEFINE data or functions that are actually implemented in .c/.cpp/etc files.

I can agree with this statement for the data part but not for the code part.
Only code implemented in the header can be inlined by the compiler. This can save program space and stack space and is fully documented feature.
See wiki for more info on inline  http://en.wikipedia.org/wiki/Inline_function

Best regards
Jantje
Do not PM me a question unless you are prepared to pay for consultancy.
Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -

westfw

Quote
Only code implemented in the header can be inlined by the compiler

Or code in the same source .c file that it is used in can get inlined.
Yes, there's an "except for code that you want to be inlined" clause in there somewhere.  Functions that actually have an "inline" attribute, or even "static inline", or implemented as macros...

Quote
you were misunderstanding the purpose of those .h files.

I think YOU are misunderstanding the purpose of .h files in general.  But I'm only going by the standards of companies/systems that have more modules than you have lines of code.  If you have c code, it should go in .c files and get included in your overall build via the linker.  The .h files are then necessary to specify the apis of these various .c files to each other.

For Arduino only, you can also have multiple .ino files that will be concatenated together before compiling them.

westfw

(It DOES seem to be the case that avr-gcc makes "wrong" decisions about inlining functions, given that it uses a -Os optimization level that is supposed to optimize for size.   That MIGHT be because it's optimizing based on the size of its "intermediate machine-independent representation" without realizing that for AVR specifically, call setup/return and 32bit math is somewhat large.  Or it could be for some other reason, or it could just be broken in some way.  Optiboot needs "-fno-inline-small-functions" or it will exceed its size limit...)

pYro_65

Its a reasonable rule of thumb, however not for every occasion.
When creating a template, unless you provide a template specification, everything goes in the header.
Forum Mod anyone?
https://arduino.land/Moduino/

Go Up