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!
Erik,
Please compare the following quotations:
http://www.keil.com/forum/docs/thread8109.asp
in which you state that
Portable code for a uC you have got to be kidding. That is one of those absolute fallacies that keep coming up.
and now
the basest form of portablity is that any working code is a useful template for writing same for another processor
Chameleon!
I think Chameleon! is being a tad unfair.
Looking through his postings, it appears that he has problems in differentiating between hard facts and opinions.
It's more likely that the poor bloke just gets confused.
At the time the first post was posted the discussion made it clear that my post referred to Portable code in the meaning that you can take the code 'as is' and use it on another processor for a uC you have got to be kidding. That is one of those absolute fallacies that keep coming up.
and now when 'portability' is discussed in the form of using what you have as a reference
the basest form of portablity as in the advantage of having done it before is that any working code is a useful template for writing same for another processor
Erik
Here is a dictionary definitions of "portability":
portability operating system, programming
The ease with which a piece of software (or file format) can be "ported", i.e. made to run on a new platform and/or compile with a new compiler. The most important factor is the language in which the software is written and the most portable language is almost certainly C (though see Vaxocentrism for counterexamples). This is true in the sense that C compilers are available for most systems and are often the first compiler provided for a new system. This has led several compiler writers to compile other languages to C code in order to benefit from its portability (as well as the quality of compilers available for it). The least portable type of language is obviously assembly code since it is specific to one particular (family of) processor(s). It may be possible to translate mechanically from one assembly code (or even machine code) into another but this is not really portability. At the other end of the scale would come interpreted or semi-compiled languages such as LISP or Java which rely on the availability of a portable interpreter or virtual machine written in a lower level language (often C for the reasons outlined above). The act or result of porting a program is called a "port". E.g. "I've nearly finished the Pentium port of my big bang simulation." Portability is also an attribute of file formats and depends on their adherence to standards (e.g. ISO 8859) or the availability of the relevant "viewing" software for different platforms (e.g. PDF).
The ease with which a piece of software (or file format) can be "ported" that, to me, reads "everything is portable, some more than other". If 'portability" is the ease, then a bit of ease is still the ease.
And then it contradicts "It may be possible to translate mechanically from one assembly code (or even machine code) into another but this is not really portability".
I would conclude that either nothing is portable or everything is portable. Whether you think it is portable depend on your definition of "the ease"
Yes, I know it's useless, but it makes me feel special; and it breaks the monotony of my otherwise boring day!
well, you ported us to the three-figure realm!
A while ago, I needed to port some 8031 assembler modules to run on an ARM core.
Could have taken the algorithms and re-coded in C, but the route I took was to write an 8031 emulator (without SFR/hardware emulation) to run on the ARM.
The result was some 8031 code that executed faster on the ARM core than it did on the original 8031.
It was a quick porting operation, it was done within the required timeframe, it was done well within the limits of the ARM board I had available and it worked.
Not sure if I'd consider writing an ARM emulator for the 8051 though!
Thinking that you can prove black==white is nothing to be proud of.
You only think that because you have failed to understand what goes before it.
What on earth is going on inside your head?
At the time the first post was posted the discussion made it clear that my post referred to Portable code in the meaning that you can take the code 'as is' and use it on another processor
Assuming you add 'recompile it' to that sentence, well done!
you have got to be kidding. That is one of those absolute fallacies that keep coming up.
Oh.. you've spoiled it now.
And there we go again - off in a quantum orbit round planet Zarg.
Arthur,
that is no surprise.
How elaborate was your emulator? How long did it take to make (or was it inherited...)? And why did you not choose to re-write your algorithms in C?
That is one of those absolute fallacies that keep coming up. Oh.. you've spoiled it now.
Of course, when I correctly call your obsession a fallacy, your knickers get in a knot and send you off in a quantum orbit round planet Zarg. I have throughout this thread, and will again, emphasize that I am talking about "small embedded", not Megabyte projects and ask everyone to read my statements with that in mind. Many exchanges in this thread have been totally obfusciated by a "small embeddeed" statement getting a "general computing" response or vv.
I do not give a hoot about "general computing facts" but really care about "small embedded computing facts"
then a bit of [GREY] ease is still the ease.
Tamir,
How elaborate was your emulator?
It emulates all instructions of a standard 8031 - There is VERY little SFR emulation; because the code was more data manipulation than interfacing.
How long did it take to make (or was it inherited...)?
It took about three days to write and test. I looked for opensource and other code examples, but found them lacking (aka buggy); especially when it came to some of the slightly more esoteric instructions (like BCD arithmetic). I based it on a disassembler I had previously written; so all the big switch statements etc were already available to me.
Fortunately, the 8031 is a fairly dumb processor and the emulation is not complicated - At the level I required.
And why did you not choose to re-write your algorithms in C?
Because a lot of it was written about 25 years ago by people who had long since left the company. In those days, comments, layout and general structure were not so well refined (at least, not in our company). There was a fair amount of code there and it just looked like it would take too long a time.
Most importantly, the base code was known to work and I did not want to introduce any nasties in the porting procedure.
Since then, I have rewritten a number of the modules in C; mainly in my spare time. Each has taken a more than the time I took in writing and testing the emulator.
For me, it was the best 'get you going quick' solution, though I would admit it might not be best for every occasion.
sounds like an excellent piece of programming. cheers!
Is this word salad day?
Did you have a point or do you just like posting for the sake of it?