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!
Do you think that what the help desk did was stupid, or that my statement was stupid? I don't think so! If you mean the later, well, good luck to you in verifying your software consistency and your test plan! what the help desk did was stupid, I thought that was crystal clear.
there is an expression "do not change horses in the middle of the stream"
Erik
Vince, what you write is very true, but to make code 'portable' for that laundry list would make the portability effort far exceed the effort put in the working code.
I have been through a compiler change ot two and, in each case, said to myself, thank heaven for CodeWright.
A port (of non-portable code) is relatively painless when you have an intelligent editor.
However, there are some things that both make coding and porting easier such as, for example, the small example of mine below.
// pointer in data in #define U8DI unsigned char idata * data // data idata #define U8DX unsigned char xdata * data // data xdata #define U8IX unsigned char xdata * idata // idata xdata #define U8XX unsigned char xdata * xdata // xdata xdata #define U8IC unsigned char code * idata // idata code #define U8DC unsigned char code * data // data code #define U8XC unsigned char code * xdata // xdata code #define U8CC unsigned char code * code // code code #define U16DX unsigned short xdata * data // data xdata #define U16IX unsigned short xdata * idata // idata xdata #define U16CC unsigned short code * code // code code #define U16DC unsigned short xdata * data // data xdata #define U32DX unsigned long xdata * data // data xdata #define U32DC unsigned long xdata * data // data xdata
I even went to my boss at the time to complain but to no avail. but what can you expect from somebody that makes statements like this: "I won't ask him why he does not bother to run a static code analyzer, because then I will have less ammunition to bust his ass if it does wrong". shocking, really.
Please explain these two:
#define U16DC unsigned short xdata * data // data xdata #define U32DC unsigned long xdata * data // data xdata
Your U16DC seems to be a U16DX and your U32DC seems to be a U32DX.
thanx,
I evidently got an old uncorrected one.
I am working from home and much stuff has not ben made urrent