TMS320F28377D: Wrong address calculations when the project is compiled with optimization level greater than 1

Those assembly code fragments compute the same value.  The --opt_level=2 build computes that value into XAR6.  The --opt_level=1 build computes that value into ACC.  The confusing part is that the --opt_level=2 build uses the value 44658 directly.  The --opt_level=1 build loads 22284 into AH, then uses AH << 1 to compute 44658.

Thanks and regards,

-George

Dear George,

thank you for your quick reply and support.

I understand that the two code fragments are different as a consequence of the different optimization levels, but the code compiled with --opt_level=2 does not work.

I will try to give a more detailed explanation of the problem.

When 2837xD_FLASH_lnk_cpu1.cmd is added to the project, the code is compiled with --opt_level=2 and executed on a TMS320F28377D, the following events occur:

1) the MyStruct_Init() function, as expected, allocates an array of MAX_NUM_STRUCTS  pointers to 'MyStruct' structures into the heap and saves its address (0xA802) into the 'MyStructsPtrs' variable;

2) The MyStruct_Create(..) function, as expected, allocates a new 'MyStruct' structure into the heap, saves its address (0xA818) into the first entry of the array pointed by the 'MyStructsPtrs' variable and returns the value 0xA8F4 as identifier of the new structure;

3) The assembly code corresponding to the first part of the  MyStruct_SetPointers(..) function performs the following - wrong I believe - operations:

3a) the AL register, which contains the identifier of the created 'MyStruct' structure and whose value is therefore initially equal to 0xA8F4, is shifted left by one bit and the result (0x151E8) is saved into the ACC register;

3b) The address stored in the  'MyStructsPtrs' variable (0x802) is added to the value stored into the ACC register and the result (0x151E8 + 0xA802 = 0x1F9EA) is saved again into the ACC register;

3c) the value stored into the ACC register is moved to the XAR4 register;

3d) the constant/immediate value 0xAE18 is stored into the XAR0 register;

3e) the value stored at address XAR4 + AR0 = 0x1F9EA + 0xAE18 = 0x2A802 is copied to the XAR6 register but the address 0x2A802 is not associated to any valid memory (it falls between GS15 RAM and CPU2 to CPU1 MSGRAM) and therefore the XAR6 register is erroneously set to zero;

3f) the addresses of var1, var2 and var3 are therefore not written to the 'first_pointer', 'second_pointer' and 'third_pointer' members of the created structure but to the addresses 0x4, 0x6 and 0x8 respectively because being XAR6 = 0, the successive code believes that the structure is placed at address 0x0 (the offset of the 'first_pointer' member is 0x4).

So a memory corruption occurs (32-bit locations at addresses 0x4, 0x6, 0x8 are erroneously overwritten) and any other code which uses the values stored in the 'first_pointer', 'second_pointer' and 'third_pointer' members of the created structure will probably fail.

I hope that the above explanation will help you figure out what could be the problem.

Best Regards,

Alberto

Please understand that for an array reference like ...

array[expression]

The assembly code generated by the compiler computes the address ...

base_address(array) + (expression * sizeof(one element of the array))

That is, the index expression of the array is always scaled by the sizeof an element of the array.  In the case of this array reference ...

MyStructsPtrs[MyStructID - FIRST_ASSIGNED_STRUCT_ID]

The expression MyStructID - FIRST_ASSIGNED_STRUCT_ID is multiplied by 2 (the sizeof a pointer). 

I think the root of the problem is confusion over what FIRST_ASSIGNED_STRUCT represents.  I suspect you view it as an address, while the compiler views it as an array index that requires scaling.  

If I'm right, then this code fails no matter what level of optimization is used.  I cannot explain how it works when --opt_level=1 (or less) is used.

Thanks and regards,

-George

Dear George,

thank you very much for your reply and your time.

I think the problem is not how I see or interpret the code but how the compiler sees it.

The difference (MyStructID - FIRST_ASSIGNED_STRUCT_ID) is just a difference between two integer numbers (identifiers, not addresses) whose result is the index of the array entry of interest.

In particular FIRST_ASSIGNED_STRUCT_ID is the identifier assigned to the first created MyStruct structure, (FIRST_ASSIGNED_STRUCT_ID+1) is the identifier assigned to the second created MyStruct structure and so on.

In this way the index of the array entry corresponding to the MyStruct structure of interest can be obtained by simply performing the above mentioned difference.

This works because the address of the first allocated MyStruct structure is saved into the first entry of the MyStructsPtrs[] array, the address of the second allocated MyStruct structure is saved into the second entry of the MyStructsPtrs[] array and so on.

The address to be stored in XAR6 (ACC in case opt_level <=1)  should be calculated exactly how you stated in your reply:

StructPtr = *((MyStruct **)(MyStructsPtrs + 2 * (MyStructID - FIRST_ASSIGNED_STRUCT_ID))) = *(0xA802 + 2 * (0xA8F4 - 0xA8F4)) = *(0xA802) = 0xA818

However, as explained in the previous reply, when the optimization level is greater than 1, XAR6 = StructPtr = 0x0.

The address calculations done by the compiler are evidently wrong when opt_level is greater than 1 .

On the contrary, when the code is generated with optimization level lower than 2, the following (correct) operations for the first part of the  MyStruct_SetPointers(..) function are performed:

3a) the constant/immediate value 0x570C is loaded into the AH register;

3b) the AL register, which contains the value (0xA8F4) of the passed MyStructID parameter, is added to the AH register and the result is again stored in the AH register. This operation performs the above mentioned difference and in fact AH is zero at the end of the operation;

3c) the ACC is loaded with the value of AH shifted left by one bit: this performs the multiplication by 2 of the above mentioned difference since every MyStructsPtrs[] array entry is a pointer and therefore composed of two 16-bit words;

3d) The address stored in the  'MyStructsPtrs' variable (0x802) is added to the value (0x0) stored into the ACC register and the result (0x0 + 0xA802 = 0xA802) is saved again into the ACC register;

3e) the value (0xA802) stored into the ACC register is moved to the XAR4 register;

3f) the value (0xA818) stored at address XAR4 + 0x0 = 0xA802+ 0x0 = 0xA802 is copied to the ACC register;

So at the end the ACC register contains the address (0xA818) of the allocated MyStruct structure, as it should be.

I do not exactly understand what kind of optimization the compiler is trying to perform when opt_level >= 2 but, from the register values coming out during the calculations, I can guess that only the least significant 16 bits of the address (0x2A802) calculated at point 3e) of my previous reply should be used for accessing the value to be loaded into XAR6.

If I can, I would suggest to put MyStruct.h, MyStruct.c, main.c and a linker command file suitable for the platform into a new project and to debug it. I have appositely prepared such source files in order to make the job easier for you and your colleagues.

You will see that when opt_level >=2, the MyStruct_SetPointers(..) function writes the addresses of var1, var2 and var3 to the locations at addresses 0x4, 0x6 and 0x8 and not, as it should be, to the 'first_pointer', 'second_pointer' and 'third_pointer' members of the created MyStruct structure.

And you will also see that XAR6 is loaded with zero because an attempt is made to load it with the value of the 32-bit word located at 0x2A802, address which does not correspond to any valid memory (at least in the TMS320F28377D).

Regards,

Alberto

Thank you for your patience.  I agree the code generated by the compiler under --opt_level=2 is incorrect.  I will file an entry against the compiler, and get you a link to it.

Thanks and regards,

-George

I filed an entry.  Unfortunately, something has gone wrong with the part of the system that allows it to be viewed by customers.  Thus, I am unable to give you a link.  Just for now, I can tell you the internal ID is CODEGEN-12562.  

Once you do see it, you'll see it doesn't say much.  I was deliberately vague in the parts of the entry that are revealed externally.  This is because I have little trust in my understanding of the problem.  I want to wait until after the bug is characterized by the compiler team.  Then we will update it with an improved description.

Thanks and regards,

-George

Dear George,

thank you very much for your kind support and the time spent for reading my long replies and testing the provided code.

Effectively the problem is quite strange, it does not happen for every instruction like ArrayName[identifier - first_identifier] but it happens  for the particular code structure I provided with my test files.

Honestly I have not found the time to change the code in order to understand if the problem happens when a member offset is passed as second argument, or when variable arguments are used or when a static array is used or any combination of the above cases.

I will then keep an eye on the entry you kindly created - once it will become visible - to see what will be the final response.

Is https://sir.ext.ti.com/jira/secure/Dashboard.jspa the right place where to search for the filed entry? 

Thank you again and best regards,

Alberto

I appreciate your attempts to characterize the problem.  At this point, I suggest waiting on the compiler development team to characterize it.  I'm not certain, but I suspect the problem can occur at --opt_level=1 or --opt_level=0.  

Alberto Gaeta said:

Is https://sir.ext.ti.com/jira/secure/Dashboard.jspa the right place where to search for the filed entry? 

That is the base web address for where customers can see issues filed for the compiler.  Once I get it, I will let you know the web address for this exact issue.

Thanks and regards,

-George

many thanks