• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 55 subscribers
  • Views 2128 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Right shift and division always result in zero with CLA

dduncan
Intellectual 315 points


I'm using the F28377D.  Can someone explain how I can get the expected value (anything non-zero) for shifted_value below when using the CLA?

read_adc.cla:

#include "F28x_Project.h"
#include <stdint.h>

extern uint32_t original_value;
extern uint32_t shifted_value;

uint32_t  adc_value;

interrupt void Cla1Task7(void) {
    adc_value = AdcaResultRegs.ADCRESULT0;
    original_value = adc_value;
    shifted_value = adc_value >> 1;
}

adc.c:

...

#pragma DATA_SECTION(original_value,"CLADataLS4")
uint32_t original_value;
#pragma DATA_SECTION(shifted_value,"CLADataLS4")
uint32_t shifted_value;

...

When I monitor both original_value and shifted_value in the CPU1 watch window, original_value is exactly as expected--a 12-bit value up to 4095 (so memory would seem to be being shared correctly).  However, shifted_value is always zero.  Of note, if shifted_value is computed by dividing by two instead of shifting right by one, the result is still zero.

Here's the relevant disassembly:

     139              ;----------------------------------------------------------------------
     140              ;  33 | adc_value = AdcaResultRegs.ADCRESULT0;                                 
     141              ;----------------------------------------------------------------------
     142 00000000 0000!         MMOVZ16   MR0,@_AdcaResultRegs  ; [CPU_] |33|
         00000001 7580
     143 00000002 003C          MLSL32    MR0,#16               ; [CPU_] |33|
         00000003 7BC0
     144 00000004 003C          MLSR32    MR0,#16               ; [CPU_] |33|
         00000005 7B80
     145 00000006 0000-         MMOV32    @_adc_value,MR0       ; [CPU_] |33|
         00000007 74C0
     146                      .dwpsn  file "../LLD/CLA/read_adc.cla",line 34,column 2,is_stmt,isa 0
     147              ;----------------------------------------------------------------------
     148              ;  34 | original_value = adc_value;                                            
     149              ;----------------------------------------------------------------------
     150 00000008 0000!         MMOV32    @_original_value,MR0  ; [CPU_] |34|
         00000009 74C0
     151                      .dwpsn  file "../LLD/CLA/read_adc.cla",line 35,column 2,is_stmt,isa 0
     152              ;----------------------------------------------------------------------
     153              ;  35 | shifted_value = adc_value >> 1;                                        
     154              ;----------------------------------------------------------------------
     155 0000000a 0000          MMOVIZ    MR0,#0                ; [CPU_] |35|
         0000000b 7840
     156 0000000c 0000!         MMOV32    @_shifted_value,MR0   ; [CPU_] |35|
         0000000d 74C0

On line 155, one would expect a shift instruction--not an instruction that zeroes all 32 bits of the target value.  What am I missing?  I'm using Code Composer 6.1.3.


Thanks in advance!

  • 0
    TI__Guru 61235 points

    d,

    I can reproduce the problem.  This simple task:

    interrupt void Cla1Task1 (void)
    {
        uint32_t x, y;
        x = 100;
        y = x >> 1;
    }

    produces this asm code using compiler v15.12.2.LTS:

    _Cla1Task1:
            MMOVIZ    MR0,#0
            MMOVXI    MR0,#100
            MMOV32    @__cla_Cla1Task1_sp+0,MR0
            MMOVIZ    MR0,#0
            MMOV32    @__cla_Cla1Task1_sp+2,MR0
            MNOP
            MNOP
            MNOP
            MSTOP

    If I make x and y signed:

    interrupt void Cla1Task1 (void)
    {
        int32_t x, y;
        x = 100;
        y = x >> 1;
    }

    I get closer but still wrong code:

    _Cla1Task1:
            MMOVIZ    MR0,#0 
            MMOVXI    MR0,#100 
            MMOV32    @__cla_Cla1Task1_sp+0,MR0 
            MASR32    MR0,#31 
            MMOV32    @__cla_Cla1Task1_sp+2,MR0 
            MNOP 
            MNOP 
            MNOP 
            MSTOP

    Above, the #31 is wrong.

    I am going to move this to the compiler forum so the compiler people can take a look at it.  Unless we're missing some restriction someplace on the CLA compiler, there looks like a major bug.

    Regards,

    David

  • 0
    TI__Guru* 84285 points
    I cannot reproduce these results.
    David, what compiler options are you using?
    dduncan, same question, and also what compiler version are you using? (It is not the same as the Code Composer version.)
  • 0 in reply to Archaeologist
    TI__Guru 61235 points

    Brett,

    Compiler v15.12.2.LTS.  Here is the CCS console output for the file build:

    -----------------------

    **** Build of configuration Debug for project Lab10 ****

    "C:\\TI\\ccsv6\\utils\\bin\\gmake" -k all

    'Building file: ../ClaTasks_C.cla'

    'Invoking: C2000 Compiler'

    "C:/TI/ccsv6/tools/compiler/c2000_15.12.2.LTS/bin/cl2000" -v28 -ml -mt --float_support=fpu32 --cla_support=cla1 --tmu_support=tmu0 --vcu_support=vcu2 --include_path="C:/TI/ccsv6/tools/compiler/c2000_15.12.2.LTS/include" --include_path="C:/D/dsp/work/Solutions/F2837xD_headers/include" --include_path="C:/D/dsp/work/Solutions/Lab_common/include" -g --define=CPU1 --diag_warning=225 --diag_wrap=off --display_error_number -k --preproc_with_compile --preproc_dependency="ClaTasks_C.d" "../ClaTasks_C.cla"

    "../ClaTasks_C.cla", line 22: warning #552-D: variable "y" was set but never used

    'Finished building: ../ClaTasks_C.cla'

    -----------------------

    Let me know if you need anything else.  I can send the CCS project, although I know you do not use CCS for your builds.

    Regards,

    David

  • 0 in reply to David M. Alter
    TI__Guru* 84285 points

    Yeah, I think it would be best if you were to send me the project, as I am still unable to reproduce the problem.  Here is my test case demonstrating the correct behavior:

    #include <stdint.h>
interrupt void Cla1Task1 (void)
{
    uint32_t x, y;
    x = 100;
    y = x >> 1;
}

    % cl2000 foo.cla --cla_support=cla1 -k --symdebug:none
    % cat foo.asm
[..]
;* TMS320x280xx Control Law Accelerator C/C++ Codegen Unix v15.12.2.LTS *
[..]
_Cla1Task1:
        MMOVIZ    MR0,#0                ; [CPU_] |7| 
        MMOVXI    MR0,#100              ; [CPU_] |7| 
        MMOV32    @__cla_Cla1Task1_sp+0,MR0 ; [CPU_] |7| 
        MLSR32    MR0,#1                ; [CPU_] |8| 
        MMOV32    @__cla_Cla1Task1_sp+2,MR0 ; [CPU_] |8| 
        MNOP      ; [CPU_] 
        MNOP      ; [CPU_] 
        MSTOP     ; [CPU_]
  • 0 in reply to Archaeologist
    TI__Guru 61235 points

    Brett,

    I sent you my CCS project offline.

    I noticed you had symbolic debug off (--symdebug:none).  I had full debug.  I turned it off.  No difference.

    Other thing I notice is you are building under Unix, whereas I am using PC tools:

    ;* TMS320x280xx Control Law Accelerator C/C++ Codegen PC v15.12.2.LTS *

    Maybe the problem is limited to the Windows cgtools?  Just thinking out loud.

    - David

  • 0 in reply to David M. Alter
    TI__Guru* 84285 points
    This does appear to be a Windows-specific problem in 15.12.2.LTS. The good news is that the problem doesn't seem to occur in 15.12.3.LTS. This will require some investigation.
  • 0 in reply to Archaeologist
    TI__Guru* 84285 points
    Now tracking as CODEGEN-1538
  • 0 in reply to Archaeologist
    TI__Guru 61235 points

    d,

    Which compiler version are you using?

    Update your compiler to v15.12.3.LTS or later.  I don't see it showing up under Help->Check for Updates, but you can get it here:

    http://software-dl.ti.com/codegen/non-esd/downloads/download.htm

    I checked compilation, and the problem goes away with 15.12.3.LTS.  I also checked the latest compiler 16.6.0.STS and no problem there either.  The compiler team will analyze the issue to make sure we understand what is going on.

    After you run the compiler installer, that compiler version will still not appear in the CCS project properties compiler version pulldown list.  You need to click "More" and then "Select new compiler from file system."  Then browse to where you installed the new compiler.  After doing this once, the version will appear in the pulldown list.

    Regards,

    David

  • 0 in reply to David M. Alter
    Intellectual 315 points

    I was using the TI compiler v15.12.1.LTS, which is what came with CCS 6.1.3.00034.  Moving to v15.12.3.LTS has indeed fixed the issue.  Thanks!

    For what it's worth, I got this update by using Code Composer's prompted automatic update.  (I had skipped this until now because this previously had seemed to cause a CCS failure that led to my reinstalling--but things seem okay now.)  All of the recent Windows C2000 downloads at the link you provided gave me an error, "Installer payload initialization failed".  I hadn't had any luck trying to install version 16.6.0 of the ARM compiler tools via CCS's "Install New Software...", either.