1 Reply Latest reply on Aug 15, 2012 1:42 PM by user_2405011

    Code Density

    user_14586677

      If you are running out of FLASH space these might help -

         

       

         

      1 - If any float math minimize the number of lines you do divides, if possible convert
      to multiplies. Convert float to integer math where possible. Pay attention to factoring
      of expressions, possible operation reduction, hence code reduction may result.

         

      2 - Lines with function calls, minimize f(g()) compound typed expressions.

         

      3 - Make sure you only use a variable type no larger than needed.

         

      4 - Use unsigned variables wherever possible.

         

      5 - Watchout for structures with mixed const and ram pointers within them,
      some compilers choke on this.

         

      6 - If you are heavy on Flash, light on RAM use, convert routines to RAM based
      wherever possible.

         

      7 - Try test cases of looping structures, to see what affects code size generation.

         

      8 - Examine .lst file for code that looks wacky in bytes used, understand what
      compiler did, and consider rewrite.

         

      9 - Use inline ASM where .lst file C generation looks excessive.

         

      10 - Look at module reuse, sharing, dual purpose, to eliminate # modules 
      needed, like counters/timers....Also look at data sheets of modules that could
      serve function needed, and compare ROM/RAM requirements needed. Optimize
      global HW, like clocks VC1/2/3/Sleep, to eliminate need for other timer/counters.
      Use register routing control to "share" module from one task to another, one pin
      to another.

         

      11 - Extended library, functions within them are written to be perfectly general,
      hence larger code size, you may be able to write one with less code needed for
      your specific requirements that result in smaller code size.

         

      12 – Look for approximations to compute transcendental functions if used.

         

      13 - Although no longer supported by HiTech or Cypress, the HiTech Pro compiler
      yielded on first try ~ 40% code reduction in my design when I first converted
      to it. Then the prior comments yielded another 4 K later in design as I was up
      against 32 K Flash limitation.

         

      14 - Some compilers have a setting to optimize code size or speed, the latter
      prone to larger code size. Also look at compiler vendors web site for ap notes
      and suggestions on optimization, compilers from different vendors behave and
      optimize  differently.

         

      15 - const data, strings, etc.., look for ability to reuse common string mnemonics,
      text.

         

      16 - Pointer usage can lessen code size, see url's below. Look for function calls
      passing longs as value vs pointer, convert to latter. Compiler has to copy all these,
      if not referenced. Do not pass longs or floats as values, keep always in mind native
      machine size.

         

      17 - Most compilers will optimize when indexes, pointers, a power of 2, or divides,
      divide becomes a shift.

         

      18 - Look at how linker distributed code and data segments, sometimes you can discover
      a poor decision by linker and force code/data into certain psects using pragma constructs,
      thereby minimizing wasted ROM space.

         

      19 – When you debug generally you want to turn off optimization, as compiler/linker will
      remove code and make jumps that do not make “sense” but are the result of optimization.
      When you are up to Flash boundary you may not be able to turn it off, otherwise
      application will not load. Keep this in mind, that  your debug strategy may have to change.
      I also found if using ICE Cube that debugger may no longer report “watch” variables, this
      occurred at ~ 31.5K bytes. In either case you may want to comment out large code sections
      to effectively debug.

         

      20 – f() calls take overhead, if you only call a f() once you might eliminate it as a f()
      call and place code inline.

         

      21 – Look for f() opportunities, wherever you are coding and repeating similar  operations.
      This is obvious, but sometimes missed.

         

      22 – Check compiler on macros, to see if they are being optimized or just being used inline
      using more code space vs a f() call solution.

         

      23 – Examine compiler/linker parameter control. For example in HiTech there is the AUTOBANK
      setting that controls where local variables are stored, in my case setting to 1 lowered code
      size by ~ 250 bytes. READ the MANUAL !

         

      24 – Use inline variable declarations, vs pre declaration (compiler dependent) -

         

       This  void dosomething ( void  ) {

         

          for (  unsigned char I = 0;…..
         }

         

       Not This void dosomething ( void  ) {

         

         Unsigned char I = 0;

         

          for (  I = 0;…..
         }

         

      Some help -

         

      http://www.codeproject.com/Articles/6154/Writing-Efficient-C-and-C-Code-Optimization

         

      http://www.eventhelix.com/realtimemantra/basics/optimizingcandcppcode.htm

         

      http://www.azillionmonkeys.com/qed/optimize.html

         

      By using these techniques I was able to regain ~ 4K Bytes of code space in a 32K design, which
      I promptly used up again :(

         

      Regards, Dana.

        • 1. Re: Code Density
          user_2405011

           I like to make an addition to the list:

             

          - if you're low on RAM and you have settings stored in Flash: access them directly from Flash, don't copy to RAM

             

          - move variables from global to local (if possible), this again saves RAM

             

           

             

          One great step I made a while ago was using Huffmann compression. I had about 16K of pixeldata (bitmap) and reduced it to 7K including decoding routine.

             

           

             

          Regards,

             

          Rolf