Hello, I was browsing through older posts that deal with the painful issue of portability (http://www.keil.com/forum/docs/thread8109.asp). I was (and still am) a big advocate of programming as much as possible conforming to the C standard, and having a layered structure that allowed "plugging-in" other hardware. But I have come to change my mind recently. I am reading the "ARM system developer's guide" (excellent book by the way. I'm reading it because I want to port some C167 code to an ARM9 environment) in which chapter 5 discusses writing efficient C code for an ARM. The point is, and it is fairly demonstrated, that even common, innocent looking C code can either be efficient of very inefficient on an ARM depending on specific choices made, let alone another processor used! So, if we are talking about squeezing every clock cycle out of a microcontroller - I do not believe that portability without ultimately littering the code is possible!
Ouch... and it was only an update to the same tool type.
Changing tool vendors is the more serious 'portable' problem, so if you avoid the reliance on #pragmas, macros, and other tool dependent items, then the 'port' isn't as painful.
Remember, your code is written in a 'standard' language and not written in 'a tool.' The tool is designed to implement that standardized language. Your code may have to compensate for the tool's implementation (as expected with embedded code), and when it does, document it. Just minimize the need for it.
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
Changing tool vendors is the more serious 'portable' problem why do it? The only reason I can see for "changing tool vendors" would be that you made a mistake initially and bought bug-ridden tools. If you have project 'x' running with tools 'a' and switch to tools 'b' what is hindering that you maintain 'x' with 'a'
Erik