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!
If every last clock cycle counts then changing processor or increasing clock speed would seem a better option.
"then changing processor or increasing clock speed would seem a costlier option"
Not necessarily. Prices do change with time and popularity of components.
If every last clock cycle counts then changing processor or increasing clock speed would seem a better option. If neither of these is feasible then accept that the design is inadequate
indequate??? if it is doable, working and there are cost constrains, where do you get 'inadequate' from
Well, the system clearly hasn't been designed so that it can be programmed in 'C', but you're trying to program it in 'C'. I'd describe that as an inadequate design. Perhaps you'd prefer something like 'not up to the job'? Also, code that is written in a 'do-able' situation is likely to be an unmaintainable, non-portable mess. This in turn means increased development and maintenance costs, increased chance of unnoticed or 'marginal' bugs, and of course longer time to market.
If every last clock cycle counts then changing processor or increasing clock speed would seem a better option. If neither of these is feasible then accept that the design is inadequate, code the necessary bits in assembly
A reasonable approach, but if "processor pleasing C" will do, then why not use that?
Because you can't guarantee that a 'C' construct will compile to the same object code each time. Any change in compiler version or optimisation level may affect things, and as you will no doubt be using the highest optimisation level given that 'every clock cycle counts' any change to an unrelated area of code may alter timing in the critical parts.
then start work on the MK2 replacement system as quickly as possible.
and go bankrupt becuse your product is more expensive than the competitors.
By your logic you will have no competitors, as your product will be cheapest therefore they will be bankrupt.
If the world rotated about "standard C" and "programmers convenience" instead of business realities then ...
Business realities dictate that one should think about the total cost over the product lifecycle. This includes such things as future development, time to market, maintenance and upgrade of existing systems and so on. If you've thrown together some nightmarish hodge podge of hand 'optimised' code on some hardware running at the bleeding edge you've had it.
Please go to the nearest paharmacy and buy a dose of reality
Now I understand where you're going wrong.
Because you can't guarantee that a 'C' construct will compile to the same object code each time.
OH???? I would like you to justify yor statement re the following pseudo code:
ring_buffer[30]
ring index++ if ringindex%30 ring index = 0
as ooposed to ring buffer[32] ring index++ ring index &= 0xc0
I have no doubt what is the most "processor pleasing C" and no optimization will change which is the most efficient.
Erik
It would be difficult to justify anything more than a career flipping burgers from the following code:
The intent in your first example doesn't offer the same opportunity for optimisation as the second. Providing bits of 'code' that *try* to do different things isn't really on, is it?
Here's a challenge for you: convert your 'pseudo-code' back into 'C' by removing the spaces from the variable names and replacing the semicolons, then see if you can spot the errors.