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: Compiler problem - large global arrays

Tool/software: TI C/C++ Compiler

Hello,

Working on TDA2xx, compiling for M4 and DSP cores.

When trying do define a very large global array, from some reason the actual array after compilation results in a much smaller size (can also be seen on the map file)

i.e:

unsigned char ARR[0x2A000000] result in ARR being only 0xA000000 bytes.

This happens both with M4 compiler (tried on versions TI.5.2.8 & TI.16.9.2.LTE) and with DSP compiler (tested with version  v8.1.0 )

Can you please help resolve this problem ? 

(B.T.W this happens also when i tried to split the total size into several dimensions and defining a multidimensional array (ARR[][][] ..))

Thanks

Guy

  • Starting in later compiler releases (ARM_16.9.7 and C6000 8.1.6 for the branches you mentioned) the compiler emits an error message when it can't allocate a data object large enough, instead of silently truncating the object.  This defect was tracked as CODEGEN-449.

    Additionally, new compiler releases as of August will now support allocating up to the largest possible object size.  For ARM, this will be the upcoming 18.8.0.STS.  The next feature release for C6000 is currently unplanned.  This is tracked as enhancement CODEGEN-4042.

  • Hello, Thanks.

    What is the reason the compiler cant allocate large arrays?
    if it is a bug, is there a way to work around from the source code or is the only way is to create a memory hole using the linker file and assign pointer to it instead of defining an array in the C source?

    Thanks
    Guy
  • Guy Mardiks said:
    What is the reason the compiler cant allocate large arrays?

    There is a limitation imposed by low level details of the implementation of the compiler.  We plan to fix it.  But, this particular fix is more difficult than most.

    Guy Mardiks said:
    if it is a bug, is there a way to work around from the source code

    Unfortunately, no.  Creating a hole in the linker command file is a solution worth considering.

    Thanks and regards,

    -George