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!
i is being thinked you is right and verry interesteding
now kalib changse the 8051 code to ARM7 and ARM9 and seeing the big wanting of care in the code,,, and is being good with the luck or have gooder 8051 code
i also being with the system book and is not reading yet and i looking chap 5 sooner
projects kalib doed with jumping tabels with low assemlber and with high c in the aplicaption
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!
You might find this interesting:
www.brainhz.com/.../results2006.html
:)
Then again, portability and efficiency often are diametral opposites. And portability only means that it can be compiled for and run on different platforms, not that it has to be fast.
Tamir,
The thread you gave shows some absolute classic Erik Malund vs Jack Sprat discussions!
Where has Jack gone I wonder?
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
Christoph, Thanks for the link. Very entertaining indeed!
Tamir
I would say you are right. When "squeezing every clock cycle out of a microcontroller" it is likely not the translate with the same benefits. But, don't forget that 'portability' also means the ability to change compilers and not just processors.
Just because that construct is optimized if implemented this way, doesn't mean the next compiler will optimize it with the same zeal.
I think when it comes to writing code that is 'portable' the odds are slim that between processors it actually 'ports' without extensive modifications, but the writing code that is tool independent becomes a real 'portability' payoff issue.
Although the cross-compilers are very efficient these days, if you are relying on "squeezing every clock cycle out of a microcontroller" you should suspect that your hardware design is underpowered. Sometimes fixable, sometimes not. If you not beef-up the hardware performance, just document the hell out of the code that compensates for the deficiency.
NOTE: 10 or 15 (or, uhm, 20 to 25) years ago you REALLY had to watch those peas-n-queues when writing in "C".
I prefer to err on the side of highly-readable, reliable, and maintainable code than the 'extra' micro-seconds saved here-n-there. It pays off in the long run.
(...and no, I didn't read the linked thread, so if I'm opening an old wound, forgive me)
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
I would absolutely go along with what Erik has written.
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.
Vince, You mentioned changing the compiler. Indeed, I ignored that possibility in the original post, but your comments remind me of a "war story". A couple of years ago I was working on a certain product involving many developers, all working in parallel. I used to build my software using a network link to gcc, so to my surprise one morning it did not work anymore, despite the lack of any network problems. Calling the help desk revealed the reason: They just downloaded the latest revision of the compiler, and were busy installing it. I mean, we were in the middle of a development effort! It is like somebody pulls the rug underneath your feet. My complaints didn't help, and the product did hit the market (it failed, but not because of low software quality. there were much better products out there).
Ouch... and it was only an update to the same tool type.
Changing tool vendors is the more serious 'portable' problem, so if you avoid the reliance on #pragmas, macros, and other tool dependent items, then the 'port' isn't as painful.
Remember, your code is written in a 'standard' language and not written in 'a tool.' The tool is designed to implement that standardized language. Your code may have to compensate for the tool's implementation (as expected with embedded code), and when it does, document it. Just minimize the need for it.
Changing tool vendors is the more serious 'portable' problem why do it? The only reason I can see for "changing tool vendors" would be that you made a mistake initially and bought bug-ridden tools. If you have project 'x' running with tools 'a' and switch to tools 'b' what is hindering that you maintain 'x' with 'a'
They just downloaded the latest revision of the compiler, and were busy installing it. I mean, we were in the middle of a development effort!
that is udder (bovine) stupidity.
much to the surprise of many I am trying to be nice, ableit direct and to the point, thus rarely use this word.
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, 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!
Better companies tries to use "build servers" whenever possible, where all software is built on a reference platform.
A compiler upgrade is then performed on another machine or in a sand box. Then a product is built with the new tool, followed by some extensive tests to verify that all test cases (and there should be a large set of documented and preferably automatically testable cases) produces the expected result.
First then may there be a decision that a specific product should switch to the new compiler version. But that decision will still only affect a specific application, or new applications that are early in their development cycle.
Each and every mature product should then be migrated one-by-one after proper validation.
After all products has been migrated, the original build environment should still be kept in working order, in case there is a need to jump back to an old software version and produce a branch with a fix for some detected problem and where the customer refuses to make a big upgrade to the latest and greatest version.
For some products, the customer really do reqruie that they get bug fixes for the version they are running, instead of having to upgrade to a newer version that they haven't tested and accepted. And the acceptance tests can take very long time - many months or more. Obviously the bug fixes should be built with exactly the build environment that was used for the original release.
Virtual machines can be very valuable when it comes to build environments, since a single machine can then host a number of perfect sand-boxed installations, all left in pristine order. Not only that, but the virtual machines can be saved and later restored to newer hardware without breaking the installation. With a native installation, you loose your reference build machine if the motherboard dies and is too old to be replaceable.
"Do you think that what the help desk did was stupid [...]"
Are you sure that it was the help desk that attacked your build environment? A number of other words comes to my mind...
I would say that the company has a management problem if any changes to the build environment isn't synchronized with a contact person for each and every project that will be (or at least may be) affected.
A vice president would be quite mad if his electronic diary is suddenly off-line or upgraded to a different program without 100% synchronization of all entered information - and 100% compatible with the local copy stored on his laptop.
A mechanic who finds that some of his wrenches has suddenly been replaced with metric instead of inch (or the reverse) size steps would take his heaviest sledge hammer and go find the culprit.