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.

Compiler/TMS570LC4357: assembler modulo operator broken?

Part Number: TMS570LC4357

Tool/software: TI C/C++ Compiler

The TI assembler (ARM CGT 16.9.6 LTS, in CCS 7.4.0) objects to the expression "1 << (121 % 32)" (the result of some macro expansions), claiming a value out of range.  121%32 is 25 = 0x19, which is certainly in range for a shift count, and indeed there is no problem with "1 << 25".

To investigate, I put ".word 121 % 32" in a place where I could find the result in the binary.  What I see, both in CCS memory dump and in visual inspection of the SREC file, is 0x0000AC19 (!).  No wonder it's out of range for a shift count... the bottom byte is the right value, but where is the "AC" in the next byte coming from?  If I change 121 to 122, I get 0x0000B31A; 123 gives 0x0000BA1B.

The problem appears to be assembler-specific; the C compiler's % operator works correctly.  The assembler's divide operator also works correctly.

  • I am unable to reproduce this problem.  I'd appreciate if you would submit an assembly file I can build to see the problem.  It would be best if this assembly file includes no other file, or you have to submit all those files as well.  Also show exactly how the file is built, by copy-n-paste from the Console view.  

    So you can attach the source file to your next forum post, you need to add the file extension .txt.  That is because the forum only accepts a few different kinds of file for attachments.

    Thanks and regards,

    -George

  • The source is as follows.  Attached are a copy of this as a file; the console log, showing all well; and an assembler listing, showing the incorrect code generated.

        .sect ".intvecs"
        .arm
        .def _c_int00
    _c_int00:
        b _c_int00
        .word 121 % 32        ; result should be 25 = 0x19, is 0xAC19
        .word 122 % 32        ; result should be 26 = 0x1A, is 0xB31A
        .word 123 % 32        ; result should be 27 = 0x1B, is 0xBA1B

    The first five lines are just the boilerplate to make it build.    The SREC output is:

    S00600004844521B
    S31500000000EAFFFFFE0000AC190000B31A0000BA1B9D
    S70500000000FA

    which shows the erroneous results.

    	.sect ".intvecs"
    	.arm
    	.def _c_int00
    _c_int00:
    	b _c_int00
    	.word 121 % 32		; result should be 25 = 0x19, is 0xAC19
    	.word 122 % 32		; result should be 26 = 0x1A, is 0xB31A
    	.word 123 % 32		; result should be 27 = 0x1B, is 0xBA1B
    
    **** Clean-only build of configuration Debug for project trymod ****
    
    /home/hspencer/ti/ccsv7/utils/bin/gmake -k -j 8 clean -O 
     
    rm -rf  "trymod.srec"  "trymod.out" 
    rm -rf "source/intvecs.obj" 
    rm -rf "source/intvecs.d" 
    Finished clean
     
    
    **** Build Finished ****
    
    **** Build of configuration Debug for project trymod ****
    
    /home/hspencer/ti/ccsv7/utils/bin/gmake -k -j 8 all -O 
     
    Building file: "../source/intvecs.s"
    Invoking: ARM Compiler
    "/home/hspencer/ti/ccsv7/tools/compiler/ti-cgt-arm_16.9.6.LTS/bin/armcl" -mv7R5 --code_state=32 --float_support=VFPv3D16 -O1 --opt_for_speed=2 --include_path="/home/hspencer/ccs/workspace_v7/trymod" --include_path="/home/hspencer/ti/ccsv7/tools/compiler/ti-cgt-arm_16.9.6.LTS/include" -g --c99 --diag_suppress=10205 --diag_warning=225 --diag_wrap=off --display_error_number --issue_remarks --enum_type=packed --asm_listing --preproc_with_compile --preproc_dependency="source/intvecs.d_raw" --obj_directory="source"  "../source/intvecs.s"
    Finished building: "../source/intvecs.s"
     
    Building target: "trymod.out"
    Invoking: ARM Linker
    "/home/hspencer/ti/ccsv7/tools/compiler/ti-cgt-arm_16.9.6.LTS/bin/armcl" -mv7R5 --code_state=32 --float_support=VFPv3D16 -O1 --opt_for_speed=2 -g --c99 --diag_suppress=10205 --diag_warning=225 --diag_wrap=off --display_error_number --issue_remarks --enum_type=packed -z -m"trymod.map" --heap_size=0x800 --stack_size=0x800 -i"/home/hspencer/ti/ccsv7/tools/compiler/ti-cgt-arm_16.9.6.LTS/lib" -i"/home/hspencer/ti/ccsv7/tools/compiler/ti-cgt-arm_16.9.6.LTS/include" --reread_libs --diag_wrap=off --display_error_number --warn_sections --xml_link_info="trymod_linkInfo.xml" --rom_model --be32 -o "trymod.out" "./source/intvecs.obj" "../source/linkflash.cmd"  -llibc.a 
    <Linking>
    Finished building target: "trymod.out"
     
    Building files: "trymod.out"
    Invoking: ARM Hex Utility
    "/home/hspencer/ti/ccsv7/tools/compiler/ti-cgt-arm_16.9.6.LTS/bin/armhex" --romwidth=32 --motorola=3 -o "trymod.srec"  "trymod.out" 
    Translating to Motorola-S3 format...
       "trymod.out" .intvecs ==> .intvecs
    Finished building: "trymod.out"
     
    
    **** Build Finished ****
    
    
    TI ARM Assembler Unix v16.9.6 Tue Dec 10 17:13:04 2019
    
    Tools Copyright (c) 1996-2017 Texas Instruments Incorporated
    ../source/intvecs.s                                                  PAGE    1
    
           1 00000000                   .sect ".intvecs"
           2 00000000                   .arm
           3                            .def _c_int00
           4 00000000           _c_int00:
           5 00000000 EAFFFFFE!         b _c_int00
           6 00000004 0000AC19          .word 121 % 32          ; result should be 25 = 0x19, is 0xAC19
           7 00000008 0000B31A          .word 122 % 32          ; result should be 26 = 0x1A, is 0xB31A
           8 0000000c 0000BA1B          .word 123 % 32          ; result should be 27 = 0x1B, is 0xBA1B
    
    No Assembly Errors, No Assembly Warnings
    

  • Thank you for the test case.  I can reproduce the same result.  This is a known issue.  Among 16.9.x.LTS releases, it is fixed in versions 16.9.7.LTS and higher.  It is also fixed in all versions 18.1.0.LTS and higher.  If you use CCS, please see this page to learn about upgrading features in CCS, including the compiler.  Or, if you prefer, standalone downloads of the compiler are also available.

    Thanks and regards,

    -George