views:

143

answers:

1

I'm writing mostly embedded code at work. We have a big long-term project that's been developed, and has several generations, and now the processor for which it was written is being discontinued and it might be impossible even to continue using processors from the same manufacturer. (The transition will be probably from TI to Renesas FPU-microprocessors). Part of the problem is that some code is written in assembly.
I'm looking for ways to make the transition as painlessly as possible, and make it smoother if such a transition is needed in the future.
What can you suggest?

+12  A: 

Produce a generic C version of as much of the code as possible.

This may seem like a waste of time if your intent is for the final implementation to be in hand-optimised assembly, but it really really is not.

When optimising for a new target, you can rewrite key sections in assembly, but having a C version will firstly let you have something up and running very quickly on each new target, and secondly provide a readable reference implementation to compare against when optimising, both of which will make your life much, much easier.

Moreover, realise there is no need for everything to be hand optimised assembly, just the sections of code where most time is spent / that take up the most space. To write all of a large project in assembly is almost certainly to waste effort unnecessarily. The rest can just stay as generic C. But you won't know what you should focus on until your C version is up and running and you can profile it. You can guess, but you won't know.

moonshadow
Agreed: all but the most simpleminded C compilers do a good job of instruction scheduling and register coloring, so long as you're willing to make the job easy for them. I routinely get 1 IPC or better from my native C routines, through adjustments based on careful attention to the disasm output.
Crashworks
Agreed! Assembly is for engineers that don't know any better.
Nate
Yes, very good answer
none