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.
Here is the code snippet -
container.slice++
if(container.slice == NR_SLICE_INSLOT)
{
container.slice = 0;
container.slot++;
if(container.slot == NR_SLOT_INFRAME)
{
container.slot = 0;
container.box++; // Line1
if(container.box == NR_FRAME_OF_BOX) // Line2
{
container.box=0;
}
}
}
Its corresponding (code after "container.slot = 0;") assembly generated -
STB .D1T1 A6,*A3 ; |2072|
LDHU .D1T1 *A4,A3 ; |2073|
NOP 4
ADD .D1 1,A3,A3 ; |2073|
STH .D1T1 A3,*A5 ; |2073|
LDHU .D2T2 *B4,B5 ; |2074|
MVKL .S2 _container,B4 ; |2076|
MVKH .S2 _container,B4 ; |2076|
NOP 2
ZERO .D2 B5
|| CMPEQ .L2 B5,B6,B0 ; |2074|
[ B0] STH .D2T2 B5,*B4 ; |2076|
Same variable is being used in Line1 and Line2. Due to pipeline when Line1 is still executing, Line2 code will do fetch and hence will load previous value.
Am I correct here?
Hence some kind of memory barrier is required between these two lines so that barrier makes sure that all instructions completes all the pipeline stages before next instruction starts executing.
As C code is compiled with o3 optimization for speed so fix in assembly is not the solution.
I guess this is a very basic kind of problem and will have a well defined solution but I am unaware of it.
Please help or give some clue or pointer to lookupon.
Regards,
Shreshtha
Shreshtha Kumar said:Am I correct here?
No. You can learn a lot about assembly code by reading the CPU & Instruction Set Reference Guide.
You can also learn a lot about assembly code by reading the code generated by the Optimizing C Compiler. It is really good, and it understands the pipeline of the C6000 devices a lot better than any of us who have been looking at C6000 assembly code for 15 years and more.
Shreshtha Kumar said:Please help or give some clue or pointer to look upon.
Run this code with the CCS cycle accurate CPU simulator. It will single-step with cycle accuracy for all of the register behavior.
Build your test case so that your pointers will result in meaningful data showing up in the right registers and memory locations when they are supposed to.
The bigger question in my mind is, why do you think the compiler output is wrong? Is it because it 'looks' wrong, or are you getting results that you do not expect in memory?
This assembly code is not enough to decide whether there is a problem or not. Please build again with -s so that the compiler will insert comments in the assembly output. Such comments make it much easier to interpret the generated assembly. Please post that assembly so we can take another look.
Thanks and regards,
-George