AVR Freaks

Check my edit above, I posted another version.

In general I agree with you, code should be written to be readable, and therefore maintainable. However, when you are optimizing, sometimes you have to through readability out the window in order to achieve better speed, or more compact size.

It's also about context.. I actually find the optimized version of #2 to be more readable/obvious, than yours. Because what we are doing is a logical operation of loading bits, not an algebraic one of adding values. Had the operation been to say take decimal value input, and store that in a variable, then I would have used your method, showing an algebraic operation, instead of a logical one.

[edit]for my "new" version, there is no need to obfuscate with the pointer... just noticed that the optimizer picked up on the incrementing index, and simply incremented the pointer, instead of adding an offset each time. The savings in that version should be in how the loop is managed. I would expect the code to look something like:

In the end, when optimizing you need to look at the generated code first, and then make changes to your C code to try and improve on the output.

If there is one of these sequences in the program, and it runs once a second, it doesn't really matter whether it is 8 or 12 or 16 words/cycles.

If it is run repeatedly, like over a buffer every second, then one would take care to write efficiently, and that might vary a lot on the app and the compiler's code generation model. In this particular case, for example, I would take care to ensure that i & my_char ended up in registers, either implicitly due to the compiler's code generation model or explicitly. I use very little local ("automatic") data in my AVR apps, so I wouldn't do that. [that's my heresy; you asked about style]

No-one used a pointer as the "best" solution? If one could just keep pointing to the source array, then it skinnies down the source quite a bit, though i may still be needed to count.

Speaking of counting, why not just unroll the loop? A little bigger, but certainly faster, and no counting.

Everyone thinks conditional decision on 1/0 is "best"? Hmmmm--if the data is known, then a simple OR will suffice. Or a mask. Is that really always worse than the conditional?

Now, if this is a logic analyzer and has to scream through this stuff, then see if you can entice your compiler to use an index register pair for the pointer and not refresh it every pass. Or simply drop into ASM and unroll the loop. Lessee--Clear result. Set the pointer. 2-cycle LD with post-increment. AND mask the low bit [optional]. OR into result. If no mask is needed then it is about 30 cycles total, unrolled. Alternative method: BLD/BST.

Lee

The same certainly applies to my "model" of how I structure AVR apps. If it is needed to get the job done fastest, then an entirely different "feel" or "style" might be used. Including dropping into ASM if it yields significant savings.

Anyway, getting back to the quote about variable length. Interesting that we are counting cycles, yet implementing as a function. Now we are back to compiler-brand "models" of code generation. Inlining would reduce the overhead to "call" the fragment. As you mentioned, one could ask for unrolling. Do we know that the data is pure with all bits but the low bit clear? [I can't help thinking that one of these loop-guts--a few cycles/words-- each time when the data was >>created<< would make most of this go away. The bad "style" was to store the data in such a manner in the first place, some could speculate. So now we are trying to make a silk purse out of a sow's ear?] If one relaxes the style-points requirements one can create multiple entry points into an unrolled solution.

The BLD/BST gains when there is the masking requirement (the data bytes are not "pure"), and does in fact gain because neither the initialization of the result nor the shift is needed along with eliminating the mask.

True the compiler often does a good job, and it did so with the simplistic example we were working with here. But this is by no means guaranteed.

Also, you seemed to have skipped my follow-up comment to that, which hopefully adds more context.

So yes, optimizing can, and usually does, obfuscate the code. But in certain cases it is necessary. However, you cannot assume a certain construction will happen from a certain sequence (unless you are very familiar with your compiler, and even then...) as such, you need to look at the generated code to guide you in where and what to change in the source, to achieve better output.

I'm a firm believer that one should only optimize where absolutely necessary. Because the compiler usually does a very good job on it's own, unless the initial code is very poor in construction.

Having said that, to say that changes in code makes no difference, that's not true, and I showed that by counting the actual run-time cycles of each method. While they all generated the same number of words, they had quite different execution times. So if your goal was speed, making some of those subtle changes could result in a substantial increase in performance. if the routine is called often.

In the end it really depends on what your optimization goal is, speed, or size. I was always looking at it as a speed issue, while you seemed to be looking at it as a size one, as you only ever looked at word-count. You quite often have to trade one for the other, though in this case the size seems to remain relatively constant, and only speed is affected.