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!
Several heated debates, but no real "wrong" opinions.
I think the three (?) debates in this thread can be milled down to something like the following:
Writing portable code costs extra time. Writing non-portable code costs extra time.
Optimizing for a processor you don't have doesn't give anything. Optimizing for your specific processor means that you may be locked into a deficient design.
Selecting too big processor can kill a project. Selecting too small processor can kill a project.
In the end, it is a question of view, and of company policies, and volume of the product etc. The only thing that is known is that portability is not simple.
A small very partial list of stumbling stones, that can make "portable" hard to really manage: - Unix, Win32 or .NET. - 8-bit or 64-bit. - Little-endian or big-endian. - 8-bit or 9-bit characters. - Two-complement integers or sign bit. - von Neumann or Harward architecture. - uA batteries consumption or mains-powered. - Single-instruction or vector-based instructions. ...
The target environments and hardware can vary so much that there can never be "one" solution. It is so easy to think that a program can always be written in a portable way - but how fun is it really to have an algorithm that works with 36 bit integers and 9-bit characters? How many trivial lines of code would break? Anyone done (x & 0xff) and assumed a specific behaviour?
Since we can't really write the ultimate portable program, we can argue, and debate and sometimes fight a bit about what parts of "portable" that are best to think about, and exactly what weight we should give to the problem, compared to all other design decisions we have to make to manage to produce a working and sellable product that people actually want to buy.
With so varying architectures (just compare C51 to an ARM7...) it is hard to discuss specifics. An ARM chip can use a recursive algorithm, and the algorithm can be very easy to read, understand and maintain. And it would be portable to just about any processor in this world. But it would be a lousy solution for a C51 user.
But on the other hand - writing a C51 program without taking advantage of bit operations would be the ultimate stupidity, since it would waste one of the main reasons for a C51 processor.
Since there are no single correct solution, the bottom line is to think and make educated decisions. And to document them - what the decision was, and (quite important!) why it was taken.
And always remember that the price of a chip is not proportional to speed or number of supported peripherial devices. Fighting to fit everything into a tiny processor should be done because you can make 10 cent extra times 100k units, not because someone made an oops when selecting the processor.
Alas, too many products are victims of the oops design methodology...
Anyone read any threads where the OP is doing a "real" commercial job, but don't know how to read the processor documentation? Anyone think they selected the correct processor if they didn't read the documentation before selecting it?
Per, You wrote: Anyone think they selected the correct processor if they didn't read the documentation before selecting it?
these thing do occur, alas, as we all know. A couple of overseas managers are now considering switching to Linux because it seems to support some powerful processors that Windows CE does not support (yet). The problem is the performance of a system that sports a powerful MX processor. They don't even consider revising the software, which needs a) rewritng by people who know what they are doing b) careful, controlled maintenance
but instead they plan to replace the RTOS and change the prcorssor, without fully understanding the costs in terms of compatibility and maintenance. Again - shocking.