This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Code portability

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!

Parents
  • 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!
    totally agree.

    portability has its place, but not as a "It must all be portable" practice.

    writing in C you will have '90% of your code portable without "littering the code" and "littering the code" of the remaining 10% will only give you some untested stuff that may or may not work after porting.

    When I port, I take what is there as is and make the needed changes. The original code is written without #if C51, #if C166, #if XA #if ARM and all that other "littering the code".

    My experience is that it takes you 10 times longer to make code 'portable' than it takes you to port non-portable code.

    Erik

Reply
  • 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!
    totally agree.

    portability has its place, but not as a "It must all be portable" practice.

    writing in C you will have '90% of your code portable without "littering the code" and "littering the code" of the remaining 10% will only give you some untested stuff that may or may not work after porting.

    When I port, I take what is there as is and make the needed changes. The original code is written without #if C51, #if C166, #if XA #if ARM and all that other "littering the code".

    My experience is that it takes you 10 times longer to make code 'portable' than it takes you to port non-portable code.

    Erik

Children
  • I would absolutely go along with what Erik has written.

    My experience is that it takes you 10 times longer to make code 'portable' than it takes you to port non-portable code.

    I cannot give an absolute multiplier but for competent developers, in general, migrating non-portable code is preferable to creating portable code. In embedded systems, true portable code could be considered a myth.

    David.

  • In embedded systems, true portable code could be considered a myth.
    I agree - with a caveat. Some embedded systems (e.g. a cellphone) are of such a magnitude that the portability issue is of the Windows/Linux-Intel/Motorola scale and thus relevant.

    However in the 8-16 bit world "true portable code should be considered a myth".

    Erik