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.

  • Resolved

Compiler/EVMK2H: Why does the C6000 v8.2.2 compiler truncate the size of objects >= 512Mbyte ?

Guru 64680 points

Replies: 6

Views: 1219

Part Number: EVMK2H

Tool/software: TI C/C++ Compiler

When using C6000 compiler v8.2.2 to compile a SYS/BIOS 6.50.1.12 program for a C66 core in the SYS/BIOS .cfg file attempted to set the heap size to the following, which uses the majority of the 2Gbyte DDR3 region:

BIOS.heapSize = 0x7fe00000;

Which causes SYS/BIOS to generate the following array to allocate space for the heap in the SYS/BIOS generated configPkg/package/cfg/<project_name>_pe66.c source file:

/* --> ti_sysbios_heaps_HeapMem_Instance_State_0_buf__A */
__T1_ti_sysbios_heaps_HeapMem_Instance_State__buf ti_sysbios_heaps_HeapMem_Instance_State_0_buf__A[2145386496];

When the program was compiled no warnings were generated, but looking at the map file the size of the array for the heap has been truncated to 0x1fe00000 bytes rather than the size 0x7fe00000 specified in the source file:

.far       0    80000000    1fe00c08     UNINITIALIZED
                  80000000    1fe00000     (.common:ti_sysbios_heaps_HeapMem_Instance_State_0_buf__A)
                  9fe00000    00000800     66AK2H14_C66_max_sysbios_heap_size_pe66.oe66 (.far:taskStackSection)
                  9fe00800    00000200     (.common:xdc_runtime_LoggerBuf_Instance_State_0_entryArr__A)
                  9fe00a00    00000200     (.common:xdc_runtime_SysMin_Module_State_0_outbuf__A)
                  9fe00c00    00000008     (.common:parmbuf)

Inspecting the size of the symbols in the object file, by using nm --print-size shows that the compiler has truncated the size of the ti_sysbios_heaps_HeapMem_Instance_State_0_buf__A array.

I think this problem is the subject of open defect SDSCM00043877. Is it by design that the C6000 compiler truncates the size of objects >= 512Mbytes, or is it a bug?

The headline of SDSCM00043877 suggests the intended fix is to make the compiler emit a warning when the size of an object is truncated, rather that generate the requested object size.

  • This is due to a limitation in the tools.  The existing open defect record was for emitting a diagnostic and was classified as minor severity, therefore it has remained on the back log.  We will take another look at this issue and get back to you.

  • In reply to Anna Youssefi:

    Anna Youssefi
    This is due to a limitation in the tools.

    Thank you for the information.

    I found a work-around to the problem of the limitation of the compiler truncating the array used to allocate the SYS/BIOS heap was to change the .cfg file to allocate the SYS/BIOS in a different way where the linker allocates the required space:

    /*
     * Create a heap which uses the majority of the 2Gbyte DDR3 region.
     *
     * The heap is created by getting the linker to allocate the required space,
     * since simply setting BIOS.heapSize causes a C array to be used to allocate space.
     * As of C6000 compiler v8.2.2 a limitation of the tools is that the size of C arrays is truncated
     * to the least significant 29-bits (SDSCM00043877) 
     */
    var heapSize = 0x7fe00000;
    Program.sectMap[".sysmem: align=" + Memory.getMaxDefaultTypeAlignMeta() + ", type=NOINIT {__primary_heap_start__ = .; . += " + heapSize + "; __primary_heap_end__ = .;}"] = "DDR3";
    
    var HeapMem = xdc.useModule('ti.sysbios.heaps.HeapMem');
    HeapMem.primaryHeapBaseAddr = "&__primary_heap_start__";
    HeapMem.primaryHeapEndAddr = "&__primary_heap_end__";
    
    var heapMemParams = new HeapMem.Params;
    heapMemParams.usePrimaryHeap = true;
    
    Memory.defaultHeapInstance = HeapMem.create(heapMemParams);

    Perhaps the SYS/BIOS heap allocation for C6000 could be changed to work-around the tool limitation of the maximum object size by incorporating the above when BIOS.heapSize is set to a value >= 512 Mbytes.

  • In reply to Chester Gillon:

    I have escalated the priority of CODEGEN-449, Emit warning message when objects of size 256MB or larger truncated, so that this gets implemented as a bug fix on active branches.  I have also filed an enhancement request, CODEGEN-4042, to add support for allocation of objects of size 256 MB+.  

  • In reply to Anna Youssefi:

    CODEGEN-449 has been resolved.  The compiler will now issue an error if an object with size 512 MB or larger is encountered.  The program will not compile.  The enhancement record is still open; we will hopefully add support for larger object sizes in the future.

    Thanks,

    Anna

  • In reply to Anna Youssefi:

    Anna Youssefi
    CODEGEN-449 has been resolved.  The compiler will now issue an error if an object with size 512 MB or larger is encountered.

    With C6000 compiler v8.1.6 which contains the fix for CODEGEN-449 I tried compiling an object of size 512 Mbytes:

    __T1_ti_sysbios_heaps_HeapMem_Instance_State__buf ti_sysbios_heaps_HeapMem_Instance_State_0_buf__A[536870912];

    __T1_ti_sysbios_heaps_HeapMem_Instance_State__buf is of type char.

    This produces a compiler error as expected, but was initially confused by the sizes in the error message being larger than the object size in bytes:

    "C:/ti/bios_6_50_01_12/packages/ti/sysbios/heaps/HeapMem.h", line 90 (col. 18): error: Object size 4294967296 is greater than maximum supported size 4294967295

    The reported object size appears to be in bits rather than bytes, but the error message doesn't explicitly state that. Perhaps the error message could be clarified.

    Is the underlying cause of the object size limitation that the code generation tools hold the size of object as the number of bits in a 32-bit variable?

  • In reply to Chester Gillon:

    Yes, the size is reported in bits, and yes, the underlying cause is a legacy issue of internal representation.  We have a separate open enhancement to fix this for new releases.

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.