My comment does not address the code size change issue posed by Marshall. Instead I want to comment about the preference I have for using an assignment statement that gets compiled into the executable code flow. This is as opposed to using initializers on variable declarations. I prefer the assignment statement for any RAM based variables for a number of reasons. (Note that for variables or tables of the "const" type that are directly declared to be in the code address space then I see no issues with using the initializers). Here are some of my thoughts about the use of the assignment statement.

1) I like to have the variable initilization right it the code flow because it is easier to walk through code reviews to show what gets set where.

2) If code has to be flow charted due to certain company policies or governmental agency guidelines the flow chart then automatically shows the time and value that variables are set to. With global initializers it has to be handled "out of line" by some other documentation method.

3) When debugging code it is nice to be able to cause a subroutine to re-run and get variable re-initialized as opposed to always having to restart the code from a reset. The disadvantage of the reset is that one usually looses the complete context of a complex debug process that may be in place.

4) Many embedded systems require special consideration of how the start-up code works and will require this to be modified. There are some cases where the startup type initialization of global variables with initializers is not even workable. Although I've only ever had one 8052 style platform where this is the case.

5) There are some designs where RAM bankinging in external RAM may be used and code assignment statement of variables offers some flexibility of how banking is set so variables are accessible at the correct times.

Michael Karas