We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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!
At the time the first post was posted the discussion made it clear that my post referred to Portable code in the meaning that you can take the code 'as is' and use it on another processor
Assuming you add 'recompile it' to that sentence, well done!
you have got to be kidding. That is one of those absolute fallacies that keep coming up.
Oh.. you've spoiled it now.
and now when 'portability' is discussed in the form of using what you have as a reference
the basest form of portablity as in the advantage of having done it before is that any working code is a useful template for writing same for another processor
And there we go again - off in a quantum orbit round planet Zarg.
That is one of those absolute fallacies that keep coming up. Oh.. you've spoiled it now.
Of course, when I correctly call your obsession a fallacy, your knickers get in a knot and send you off in a quantum orbit round planet Zarg. I have throughout this thread, and will again, emphasize that I am talking about "small embedded", not Megabyte projects and ask everyone to read my statements with that in mind. Many exchanges in this thread have been totally obfusciated by a "small embeddeed" statement getting a "general computing" response or vv.
I do not give a hoot about "general computing facts" but really care about "small embedded computing facts"
Erik
Of course, when I correctly call your obsession a fallacy, your knickers get in a knot and send you off in a quantum orbit round planet Zarg.
How very original of you.
I have throughout this thread, and will again, emphasize that I am talking about "small embedded", not Megabyte projects and ask everyone to read my statements with that in mind.
I'm afraid that 'small embedded' is no excuse for unmaintainable, non-portable code. You may have noticed that 'small embedded' has been around with 'large codespace' for a good while. This has allowed people to a little more than just fire up the debugger and hack in a couple of hundred lines of spaghetti over a good strong cup of coffee.
The days of the electronics guy lovingly creating a great hardware design then ruining it all with 'well, it's only software, I'll just get rattling on the hex keypad for a few hours' are well and truly over. Software has become the most expensive part of even some high turnover products because of this attitude.
I've worked with a few of them - usually in their 50s, been doing electronics for 30+ years, they weren't too bad with trivial assembly but have been forced grudgingly to use 'C' because they can no longer find a single reasonable argument against it. Once they've managed to stop just trying to translate each assembly instruction into 'C' and start writing something that looks like 'C' they relax - hey, this is easy! I don't need to worry about what flags this instruction affects, I just type a=b+c and voila! It's great!
But - they won't study program design, they'll only read a 'C' book as a last resort, they learn by trying things to see if they appear to work, if they do - fine, job done. The attitude is so different than the one they take with hardware design, its weird.
So - you're not alone. But you won't be missed by those who have to pick up the pieces when you're gone.
I'm afraid that 'small embedded' is no excuse for unmaintainable, non-portable code.
apples and oranges - as usual.
If you had a bit of memory - ah that probably fades when bile replaces reasoning - you would have remembered that I hammer, hammer and hammer agin that code must be maintainable.
That portability is a joke is not a mainatainability issue. I have seen code that has been made totally non-maintainable for the sake of portability, every page has tons of #if compile = Acme ...