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!
Arthur,
The result was some 8031 code that executed faster on the ARM core than it did on the original 8031.
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?
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!