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!
again if we are discussing "large" (embedded) the statement is valid, for small embedded it is a joke.
I work primarily with small embedded and I can assure you that portability is not a joke. portability between WHAT? processors? compilers? houses? a lot of code is "automatically portable" e.g. a mathematical function and for small embedded anything beyond a "computing function" will take more effort to make portable that to port as non-portable.
re buggy pseudo-code who cares Says it all, really. when quoting me, please quote fully
"re buggy pseudo-code who cares, it did show what I ment.
Erik
when I say "portability is a joke" I do not say "porting is a joke". My basic reference is that, in the rare instance when needed, porting "non-portable code" takes far less resources than making code portable (most often code that will never be ported). With an intelligent editor (I use CodeWright) I can port a substantial chunk of non-portable code in a few hours, making the code portable would take days.
when quoting me, please quote fully
Coming from the master of quotation abuse himself that's a bit rich.
But if you insist:
re buggy pseudo-code who cares, it did show what I ment.
Says it all, really. Do you write 'real' code with such lack of attention to detail? How about your documentation?
I'm sure your answer will be 'no', but I for one am unlikely to believe that you live this double life.
Perfect engineer by day, illiterate CS101 student by might? I think not.