Linear Assembly / Assembly optimization

1) optimizing C code
This is basically a statement that you should write your C code in a manner which is efficient for the task you are trying to accomplish.  An example would be using a bubble sort vs. a quick sort algorithm to sort an array.  Clearly one is faster than the other by its means of implementation.  You can turn on all the optimization you like for the bubble sort and you will still get a bubble sort.  In effect, the optimizer will not modify your algorithm, rather it will rearrange the statements that make up your algorithm so the processor can execute the algorithm in the most efficient manner possible.

2) using compiler options
This includes enabling the optimizer but also doing things like managing code and data placement in a manner which will utilize cache operations most effectively or simply placing data and code in memory which has the fewest number of access cycles, etc.

3) linear assembly
This is in reference to writing your assembly code directly or, as you indicated, using the assembly code generated by the compiler.  In this case, it is expected that you would further hand optimize the code by looking for additional interactions between assembler statements that the optimizer cannot identify.  This can include such things as the need to check for a valid value before using it or short circuiting a generalized operation because you know the values that will be used are limited to a specific domain, etc.

Each of these approaches has its merits.  The first one maintains code in a much more portable form but it assumes which ever platform you compile it for will have the necessary processing bandwidth for the algorithm to be useful.

The second one usually includes modifying the source code slightly to coerce the optimizer to make a more effective decision than without the source code modification.  This is good for the given compiler as you can get similar results from one build to the next but can be bad if you need to migrate to another build tool or the build tool you are using gets upgraded in a manner where the optimizer makes decisions in a different way.  This is usually an approach used where you are quite familiar with the optimizer and what types of decisions it generally makes.

The third option is generally a last resort when you need to get the absolute maximum through put for your system.  Starting with pre-generated code can be a big advantage but can also hinder you if you don't keep an open mind as it can get you to focus on optimizing in the same direction the compiler did but if you started from scratch and took a different direction you may end up with even better code.  It also entails getting very familiar with the assembly instruction set, the architecture of the processor, and also the architecture of the environment the processor works within such as cache type, memory spaces, etc.

In general, the options in the order given will be a trade off between ease/speed of implementation vs. throughput of resulting code.  Just like any engineering endeavor, there are trade offs to consider.

In my experience, increasing the through put of your already optimized code by 3x is rather unlikely.  Usually speed increases of this magnitude require a new algorithmic approach or some form of reduced precision/accuracy.  These can sometimes be identified if you look at the absolute minimum requirements of your output instead of what you want to achieve.

Jim Noxon

Hi Jim,

        The suggestion/post was useful. I was on long vacation so that i could not reply it.

         On analyzing the code further, I found that some single statements takes more cycles than a function that has loops. For example a single statement involving double variable takes cycles count of about 300, but a function with a for loop involving many statements  takes cycles of just 120 cycles. What could be the reason behind this. Can this be because of double variable manipulation? If so could this be minimized?

Regards,

Pandiyarajan.P

Pandiyarajan,

Can you provide some more details, please?
Which DSP device is this for?
Which EVM or simulator are you using?
Which compiler version and CCS version?

Can you be more specific about "some single statements"? What memory or peripheral is being accessed? Is cache enabled?

Regards,
RandyP

Hi RandyP

         I am working with TMS320C64x+ processor on Code Composer Studio of Version 4.2.0.10018. The following are the information of the environment i am working on. Simulator - Texas Instruments Simulator, C64X+ CPU Cycle Accurate Simulator, Little Endian. Code Generation tools - TI v7.0.3, DSP/BIOS version - 5.41.07.24.

        Hope the below example explains what i meant by single statements.

int s32_Val1 = 0;    // an integer variable.

double d_Val2 = 0; // a double variable

s32_Val1  = (int) (d_Val2* 256);  // this is the single statement that takes about 350 cycles.

        Many such single statements involving double variables takes more cycles.

Regards,

Pandiyarajan.P

Pandiyarajan,

The C64x+ processor is a fixed-point processor, so double precision floating point operations will be slow on this processor.

I ran this on the simulator (Debug build configuration) and found the d_Val2*256 line ran in 77 cycles. What method did you use to measure 350 cycles?

Do you have cache enabled? Are you running from internal memory? Both of those would be good.

Regards,
RandyP

Hi RandyP.

          I used the TSCL register to get the clock values. I have not enabled the cache. Thanks for the suggestion about cache and the internal memory.

         As I have been working on this processor for just a month or below, i am new to many concepts of it and so i am in learning phase. Will look how to enable the cache and running it in internal memory. Meanwhile if you wish me to do something else, i am eager to hear.

Regards,

Pandiyarajan.P

With just the Cycle Accurate Simulator, it does not seem to matter if everything is placed in internal or external memory. Here is the test program that I used:

main.c said:

#include <c6x.h>

unsigned long long ullStart, ullEnd, ullCal, ullTime1, ullTime2;

void main()
{
    int s32_Val1 = 0;    // an integer variable.
    double d_Val2 = 0; // a double variable
   
    TSCL = 0;
    ullStart = _itoll( TSCH, TSCL );
    ullEnd = _itoll( TSCH, TSCL );
    ullCal = ullEnd - ullStart;
   
    ullStart = _itoll( TSCH, TSCL );
    s32_Val1  = (int) (d_Val2* 256);  // this is the single statement that takes about 350 cycles.
    ullEnd = _itoll( TSCH, TSCL );
    ullTime1 = ullEnd - ullStart - ullCal;

}

I get 77 cycles, not 350. And I get this whether I use a BIOS5 tcf file that has cache defined (but not MAR-enabled for DDR) with the program code in IRAM or DDR. And I get 77 if I use a non-BIOS project with everything in L2 or DDR.

Please try the test program above and see what results you get.

Regards,
RandyP

Hi RandyP,

            I tried the above code in a standalone project and got the same result of 77 cycles for d_Val2 = 0 and 100 for d_Val2 = other than 0.

            I verified my SRC project code and found that enabling the optimization level option -O to 3 or other values caused the cycles to shoot up to 350 instead of 77/100. Disabling the option reduced the cycle to 77/100 for that statement, but overall cycles of the project increased. Disabling and enabling the optimization level option -O in standalone project showed a different behavior than with my original SRC code.

           Could you comment on this behavior?

Regards,

Pandiyarajan.P