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!
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"
Erik
then a bit of [GREY] ease is still the ease.
Thinking that you can prove black==white is nothing to be proud of.
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?
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.
Did you have a point yes, I do and that a smoked sardine can not see it is no concern of mine
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 ...