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!
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
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!
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"
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!
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.
How very original of you.
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.
I'm afraid that 'small embedded' is no excuse for unmaintainable, non-portable code. You may have noticed that 'small embedded' has been around with 'large codespace' for a good while. This has allowed people to a little more than just fire up the debugger and hack in a couple of hundred lines of spaghetti over a good strong cup of coffee.
The days of the electronics guy lovingly creating a great hardware design then ruining it all with 'well, it's only software, I'll just get rattling on the hex keypad for a few hours' are well and truly over. Software has become the most expensive part of even some high turnover products because of this attitude.
I've worked with a few of them - usually in their 50s, been doing electronics for 30+ years, they weren't too bad with trivial assembly but have been forced grudgingly to use 'C' because they can no longer find a single reasonable argument against it. Once they've managed to stop just trying to translate each assembly instruction into 'C' and start writing something that looks like 'C' they relax - hey, this is easy! I don't need to worry about what flags this instruction affects, I just type a=b+c and voila! It's great!
But - they won't study program design, they'll only read a 'C' book as a last resort, they learn by trying things to see if they appear to work, if they do - fine, job done. The attitude is so different than the one they take with hardware design, its weird.
So - you're not alone. But you won't be missed by those who have to pick up the pieces when you're gone.
I'm afraid that 'small embedded' is no excuse for unmaintainable, non-portable code.
apples and oranges - as usual.
If you had a bit of memory - ah that probably fades when bile replaces reasoning - you would have remembered that I hammer, hammer and hammer agin that code must be maintainable.
That portability is a joke is not a mainatainability issue. I have seen code that has been made totally non-maintainable for the sake of portability, every page has tons of #if compile = Acme ...