| ??? 12/03/07 11:10 Read: times |
#147773 - Well, If you abuse the tools... Responding to: ???'s previous message |
Esko Ilola said:
There are actually several reasons why lookup tables can be costly in C - especially in embedded C. Of course they can be costly; but they do not inherently need to be costly - provided that you know what you're doing! Compilers & Assemblers are just tools - if you don't know how to use them effectively, then neither of them will give good results! If you don't know your tools, then you can easily mess anything up! One major mistake is to believe that the table is in ROM (Flash). By C definition such tables go into RAM if not told to do so. It is easy to forget to put the special keywords (depending on compiler) to make the constants be stored into ROM. That's not the fault of the compiler or the language - that's pure programmer error! The values themselves are of course stored in ROM but during the POR the reset code in CRT0 will copy them in place. I did spend numerous hours trying to figure out why I was running out of memory with ordinary strings like "This Is a String"... Again, that's inexperience - not the fault of the compiler or the language. You must've been using a very poor compiler - any decent embedded compiler should place constant strings in ROM! (clever compilers will even notice when you use the same string more than once, and only store one copy of it). Of course, there are good tools, and there are poor tools - but you mustn't dismiss the language just on the performace of one bad compiler! Another reason is the fact that when the C compiler creates the lookup code it may not be efficient. Well - if you use such a compiler, then you will obviously get inefficient code! I have seen assembly generated by a compiler that had a multiply on each lookup access. That was of course a tad more complex lookup with structures and all. OF course, a complex lookup cannot be done simply! But, driving a 7-segment display is not a complex lookup! |
