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.

Using inline version of ECPY_directWait



Hi,

I am trying to use inline version of ECPY_directWait() from framework components(version 3.21.3.34) in my code for better performance. According to API reference guide if I define the macro ECPY_DIRECTWAIT_INLINE in project settings it should just work fine. But it throws compilation errors when the macro is defined. The same issue is repeated when ECPY_INLINE_ALL is defined in order to make functions ECPY_directConfigure32() & ECPY_setFinal()  inline. It seems there is a problem with ECPY_VERSION_MACRO macro definition. Please let me know if I am missing anything. 

I am using CCS Version: 5.1.0.09000 & C6000 cg Tools 7.3.6.

You can find the build log below.

"D:/CCSV5_INSTALL_DIR/framework_components_3_21_03_34/packages/ti/sdo/fc/ecpy/ecpy_directwait.h", line 48: error #78-D: this declaration has no storage class or type specifier
"D:/CCSV5_INSTALL_DIR/framework_components_3_21_03_34/packages/ti/sdo/fc/ecpy/ecpy_directwait.h", line 49: error #66: expected a ";"
"D:/CCSV5_INSTALL_DIR/framework_components_3_21_03_34/packages/ti/sdo/fc/ecpy/ecpy_directwait.h", line 104: warning #12-D: parsing restarts here after previous syntax error
"D:/CCSV5_INSTALL_DIR/framework_components_3_21_03_34/packages/ti/sdo/fc/ecpy/ecpy_directwait.h", line 110: error #171: expected a declaration
"D:/CCSV5_INSTALL_DIR/framework_components_3_21_03_34/packages/ti/sdo/fc/ecpy/ecpy.h", line 693: warning #12-D: parsing restarts here after previous syntax error

 Regards,

Vijay

  • Hi Vijay:

        The header file ecpy_directwait.h looks correct, so either the directive is not getting defined, or the compiler is not treating the code as C language.

        A couple of things to try:

        1)  Add the lines to your source code directly (and take the define out of the project settings):

          #define ECPY_DIRECTWAIT_INLINE
    #include <ti/sdo/fc/ecpy/ecpy_directwait.h>

    2) Ensure in the makefile the C compiler is being invoked to compile the C code.

    Regards,
    - Gil

  • Hi Gil,

    Thanks for the response.

    1) I tried adding the above two lines in the source code(& undefined the macro in project settings) where ECPY_directWait() is called. It still throws the same build error.

    2)I am using C compiler(from <COMPILER_DIRECTORY>/bin/cl6x) to build the code.

    Meanwhile I tried compiling after removing ECPY_VERSION_MACRO macro before the definition of ECPY_directWait() in ti/sdo/fc/ecpy/ecpy_directwait.h (alternatively by removing ECPY_DIRTY_BITS_VERSION_MACRO from definition of ECPY_VERSION_MACRO in  ti/sdo/fc/ecpy/ecpy_util.h) & it compiled successfully. It also verifies the usage of inline version as disassembly  did not contain the symbol ECPY_directWait.

    It seems the macro ECPY_DIRTY_BITS_VERSION_MACRO is not defined anywhere. What could be the solution for this?

    Regards,

    Vijay

  • Vijay:

        Searching around the web and other forums, it seems the storage class error is often related to using C++ options in the compiler.

        Other than that, I notice that the tools version this component was validated is different than the one being used:  (7.3.6 vs 7.2.0).

         http://www.sanb.design.ti.com/tisb_releases/Framework_Components/3_21_03_34/exports/framework_components_3_21_03_34/framework_components_3_21_03_34_ReleaseNotes.html#Validation

        You might try ensuring there are no cpp options in the compiler build options, and try the same code gen version of the compiler the product was validated with.

        Otherwise, I'll ask one of the developers who might be familiar with this module, what is the deal with the ECPY_DIRTY_BITS_VERSION_MACRO (which I also don't see defined anywhere, but I don't think is causing the storage class error).

    Regards,
    - Gil
  • Gil,

    I tried using compiler tools version 7.2.0 & still face the same error. Also I do not see any C++ related compiler options/flags defined in the project settings.

    Regards,

    Vijay

  • In short, the ‘inline’ing support is still not fully released in the referenced FC version.

    Following is needed: 

    (1)    The reference to ECPY_DIRTY_BITS_VERSION_MACRO is actually undefined and unnecessary and should be removed from ecpy_util.h, so: 

            #define ECPY_VERSION_MACRO    asm (" .ref _ECPY_inlineCompatibilityKey_01"); \
                                   ECPY_DIRTY_BITS_VERSION_MACRO 

    Should be changed to:

            #define ECPY_VERSION_MACRO    asm (" .ref _ECPY_inlineCompatibilityKey_01");  

    It looks like you have already figured this out, and with the change the following ECPY functions should support inline’ing:

    • ECPY_configure16
    • ECPY_configure32
    • ECPY_wait
    • ECPY_directWait

    by defining “ECPY_INLINE_ALL” in any source where ECPY functions are called and all calls to these functions will be inlined. Alternatively you can selectively enable inlining by including function specific compile directives, e.g. #define  ECPY_DIRECTWAIT_INLINE to inline only ECPY_directWait, etc., Note that this method of enabling inlining of the said functions only affect the calls in the compilation unit where #define is used prior to including the API header. Adding these 'defines' to your compiler toolchain via -D can also achieve the same result.

     Finally, future FC releases will support the inlining of the remaining ECPY functions: ECPY_directConfigure, ECPY_directConfigure16, ECPY_directConfigure32 and ECPY_start, ECPY_directStartEdma.

     

  • Thanks for the update. Hope to see all the remaining ECPY functions with inline versions included in future FC releases.

    Also,  defining “ECPY_INLINE_ALL” with above mentioned fix still throws an error, as it tries to inline  ECPY_setFinal() function, but can't find it's header file <ti/sdo/fc/ecpy/ecpy_setfinal.h>.  So I guess I will have to define inline-ing macros for functions individually .

    Regards,

    Vijay