|
Hi, I am reading a program, found a code block like the following:
for (i=0; i<16; i++) { Bstruct.aa[i] = Btable.aa[i];}
for (i=0; i<16; i++) { Bstruct.bb[i] = Btable.bb[i];}
...
for (i=0; i<16; i++) { Bstruct.kk[i] = Btable.kk[i];}
This is a embedded program running on a MCU.
I wonder what is the benefit for the usage of the for loop like above.
|
|
|
|
|
In this particular case I don't see a real benefit for seperating the for loops, perhaps the author thought it to be easier to read? However, if there comes a time when Bstruct.aa[]/Btable.aa[] has a different number of entries than Bstruct.bb[]/Btable.bb[] then this would be easier IMO to maintain.
|
|
|
|
|
All Bstruct.aa[],bb[] ... kk[] have the same size 16.
Is there some cons for using seperate for loops? the compiler maybe optimized them in one loop in assembly?
|
|
|
|
|
econy wrote: All Bstruct.aa[],bb[] ... kk[] have the same size 16
Yes, today they do, tomorrow, who knows?
econy wrote: Is there some cons for using seperate for loops?
Using more CPU cycles because of the multiple initializations and testings (some MCUs clear thier cache when branches are executed) of i. Other than that I can't think of any.
econy wrote: the compiler maybe optimized them in one loop in assembly?
Don't know offhand, my gut tells me they wouldn't be optimized out.
|
|
|
|
|
This would depend to some extent on the target hardware and the program design. The only way to be certain would be to ask the original writer.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
No benefit, in my opinion.
Veni, vidi, vici.
|
|
|
|
|
The key is "embedded". Some CPUs, many in the embedded space, throw exceptions for misaligned data access EXCEPT for byte access. This is one way to copy data with unknown alignment (say from a socket or file) to an aligned data structure. (The original ARM chips would throw an exception, which some embedded OSs would catch and then do exactly the above internally.)
|
|
|
|