This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Need help on 8051 assembly code optimization

We are developing a product on 8051 microcontroller. We have done coding using assembly language. Right now our code size is very high and is overshooting the allocated ROM size.

We have started code optimization using “code optimizing tips†and by “optimizing the designâ€. But from “assembler and linker†I am unaware of any directive available for code optimization.

Please let me know for any tools/KEIL options which help in "Assembly code optimization" (Eg: Identifying repeated patterns, identifying duplicate expressions, removal of dead code, Suggesting right instruction etc…)

  • Let me start by saying that I'm not a C51 guy. but I can say that the RealView compiler (for an ARM), normally does not change anything in functions that are completely written in assembly (using the __asm directive at the prototype of the function), but do offer some optimization for inline assembly (inline assembly has very limited capabilities, under the RealView compiler). Is you assembly code even available for optimization?

  • Please let me know for any tools/KEIL options which help in "Assembly code optimization"

    I'm not aware of any such tools.

    Usually, the point of writing code in assembly is to have the processor execute _exactly_ the instructions specified by the programmer, without giving the tools any freedom to make changes to the code.

    Also, "highly optimized" assembly code is usually a nightmare to debug. If the code was produced by a compiler from a high-level language, it's easy to reduce the optimization level and check the un-optimized code for correct function, but it'd be hard to do that with "optimized" assembly.

    However, if you are exceeding the "allocated ROM size" which was deemed enough for the project, then maybe you should start by optimizing the ("high level") program flow and the algorithms first, and _then_ look at the actual code again. Usually, this is easier and can bring more savings and less headaches than painstakingly sifting through already-written assembly and changing it without breaking the program.

  • So, why did you choose assembler?

    As Christoph says, the whole point of writing in assembler is that you have complete and total control - which means that you must do any and all optimisation yourself!

    If you want to delegate this to tools, then you will have to use a high-level language.

    It is quite possible that a good optimising 'C' compiler and linker might produce "tighter" code than a novice assembler programmer, I think...

  • a novice assembler programmer may, indeed need to 'optimize' his assembly, a seasoned assembler programmer will automatically write optimum code (if he did not need optimum, he would use C).

    conclusion: a novice assembler programmer has the same chance as a tailor in hell, a seasoned assembler programmer does not need to optimize, it is already dome.

    sure, a seasoned assembler programmer can, occasionally, squeeze a few bytes or a few microseconds out by reviewing his code, but that would be a nominal gain.

    anyhow, if the OP would show some code it could be judged if any particular method is suboptimum

    Erik

  • But from assembler and linker I am unaware of any directive available for code optimization.

    That's because, practically speaking, there isn't any. In theory there would be "linker code packing". But I don't think you have any chance to profit from that with hand-written assembly code.

    There's no nice way of putting it, so I'll be blunt: for what you're trying to do now, the original decision to do this code in assembly was spectacularly wrong. By coding assembly you assumed complete responsibility for all aspects of the code's performance. You refused to use the help offered by the tools --- so now you need to either help yourself, or buy external help, i.e. a consultant to revamp that code.

  • There's no nice way of putting it, so I'll be blunt: for what you're trying to do now, the original decision to do this code in assembly was spectacularly wrong.
    maybe, not necessarily

    By coding assembly you assumed complete responsibility for all aspects of the code's performance.
    which, with skill and experience, is the right way to go for critical code.

    Erik

  • maybe, not necessarily

    Given what he's asking, there's really nothing "maybe" about it.

    which, with skill and experience, is the right way to go for critical code.

    True, except that the OP clearly lacks the skill, and doesn't appear eager to acquire any experience. And in that case, it's the wrong way.

  • I agree with your statement as applied to the impression given by the OP but not as a general statement.

    Erik

  • But then again: We have to balance our answers to the requirements and capabilities of the requester.