This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/TMS320f28379D: unexpeceted NOPs in compiled code

Part Number: TMS320F28379D

Tool/software: Code Composer Studio

Hey,

while I'm doing my frist steps in C2000 software development, I found that the compiler adds some NOPs into the compiled code. The optimization is set to -O3, and I use CCSv6.2.

Example:

I made this C-Code for a timing test:
        GpioDataRegs.GPATOGGLE.all = 0x80000000;
        f_reg_result = AdcaResultRegs.ADCRESULT0;
        f_reg_result += AdcaResultRegs.ADCRESULT1;
        f_reg_result += AdcaResultRegs.ADCRESULT2;
        f_reg_result += AdcaResultRegs.ADCRESULT3;
        f_reg_result += AdcaResultRegs.ADCRESULT4;
        f_reg_result += AdcaResultRegs.ADCRESULT5;
        f_reg_result += AdcaResultRegs.ADCRESULT6;
        f_reg_result += AdcaResultRegs.ADCRESULT7;
        v_result = f_reg_result / 8;
        GpioDataRegs.GPATOGGLE.all = 0x80000000;

The assembly result is this:
174         GpioDataRegs.GPATOGGLE.all = 0x80000000;
082c2f:   1E06        MOVL         @0x6, ACC
082c30:   761F002C    MOVW         DP, #0x2c
175         f_reg_result = AdcaResultRegs.ADCRESULT0;
082c32:   E2C40300    UI16TOF32    R3H, @0x0
176         f_reg_result += AdcaResultRegs.ADCRESULT1;
082c34:   E2C40201    UI16TOF32    R2H, @0x1
177         f_reg_result += AdcaResultRegs.ADCRESULT2;
082c36:   E2C40002    UI16TOF32    R0H, @0x2
176         f_reg_result += AdcaResultRegs.ADCRESULT1;
082c38:   E710009B    ADDF32       R3H, R3H, R2H
082c3a:   7700        NOP          
177         f_reg_result += AdcaResultRegs.ADCRESULT2;
082c3b:   E710001B    ADDF32       R3H, R3H, R0H
178         f_reg_result += AdcaResultRegs.ADCRESULT3;
082c3d:   E2C40203    UI16TOF32    R2H, @0x3
082c3f:   7700        NOP          
082c40:   E710009B    ADDF32       R3H, R3H, R2H
179         f_reg_result += AdcaResultRegs.ADCRESULT4;
082c42:   E2C40104    UI16TOF32    R1H, @0x4
082c44:   7700        NOP          
082c45:   E710005B    ADDF32       R3H, R3H, R1H
180         f_reg_result += AdcaResultRegs.ADCRESULT5;
082c47:   E2C40005    UI16TOF32    R0H, @0x5
082c49:   7700        NOP          
082c4a:   E710001B    ADDF32       R3H, R3H, R0H
181         f_reg_result += AdcaResultRegs.ADCRESULT6;
082c4c:   E2C40106    UI16TOF32    R1H, @0x6
082c4e:   7700        NOP          
082c4f:   E710005B    ADDF32       R3H, R3H, R1H
182         f_reg_result += AdcaResultRegs.ADCRESULT7;
082c51:   E2C40007    UI16TOF32    R0H, @0x7
082c53:   7700        NOP          
082c54:   E710001B    ADDF32       R3H, R3H, R0H
082c56:   7700        NOP          
183         v_result = f_reg_result / 8;
082c57:   E84F8018    MPYF32       R0H, #0x3e00, R3H
082c59:   761F02A0    MOVW         DP, #0x2a0
082c5b:   E2030000    MOV32        @0x0, R0H
082c5d:   761F01FC    MOVW         DP, #0x1fc
184         GpioDataRegs.GPATOGGLE.all = 0x80000000;
082c5f:   1E06        MOVL         @0x6, ACC

What is the reason for this NOPs?

Best regards,
Thomas.

  • On C28x, ordinary CPU instructions are pipeline protected.  This means the compiler never has to issue NOP instructions to handle the case where an instruction is not ready to execute.  The CPU, on it own, detects that situation and stalls.  Such is not the case with floating point instructions like ADDF32.  The compiler keeps a model of execution of these instructions.  It knows when such an instruction is not ready to execute.  When that occurs, it emits one or more NOP instructions so that the processor waits for an earlier instruction to finish.  

    All that said, for both protected and unprotected instructions, the compiler tries to schedule those instructions so that stalls or NOP's are minimized.

    Thanks and regards,

    -George