My question to Erik is how Vanilla is his style? Several postings relate to self-modifying or non-standard coding.
I have posted "in the olden days when computers were slow i did some self-modifying code, that would be AGES ago. As to 'vanila' I choose assembler if 'vanilla' C will not do. Tweeking 'optimum' C is usually a lost cause.

I suspect that we all get some satisfaction in writing the fastest or smallest hand-crafted assembler.
I have not done so for 'satisfaction' since long ago, I do it at times out of necessity.

However you need to avoid these habits for portability.
In my opinion, the only way to achieve ANY 'portability' in embedded is to have "plain vanilla" in module group a and "device specific" in module group b. That way group a is portable and group b is a rewrite.

If one or two functions do need the performance then I isolate them completely in separate source files.
see above

The AVR runs at a higher speed than most 8051s. In my experience compiled C code will execute fast enough without tweaking.
That may be your case, what I have to port is running on a 100MHz one-clocker. Fortunately the AVR sign is much smaller and amber only. This gives some 'wiggle room' so, maybe, some of what has required assembler for the large color signs can be done in C for this smallish amber sign. Thus the code I have to port (I just hired the original designer of the AVR sign as a consutant to do the basic porting and he would not know how to spell 'assembler') but I'll have to specify the 'rules' refine and maintain myself.

Erik

PS *optimum C is still 'plain vanilla' what I mean by optimum is things like being aware that a 'switch' in Keil C is a sloven process and use 'if', 'if else' instead.