• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 84 subscribers
  • Views 2246 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28379D: Type [W9999] Register write access is in the delay slot of a write of the same register

Andrean С.
Prodigy 180 points
Part Number: TMS320F28379D


Hello,

I have problems with ti-cgt-c2000_20.2.3.LTS compiler.

If optimization level of the project is set to 0 or no optimization is used then there are NO warnings. If I set the optimization level to 1 then I have the following warning:

Description Resource Path Location Type
[W9999] Register write access is in the delay slot of a write of the same register                     line 191 C/C++ Problem

In attachments, you can find .pp file as described in the article How to Submit a Compiler Test Case.

Thank you in advance!Euler2OmegaInstr.pp.txt

  • 0
    TI__Guru**** 251020 points

    Thank you for notifying us of this problem, and submitting a test case.  I am able to reproduce the same behavior.  I filed EXT_EP-10215 to have this investigated.  You are welcome to use that link to follow it.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 180 points

    Thank you very much for your answer!

    Do I need to be ready for an unexpected change of the variable in the program flow because of this issue?

    Best regards,

    Andrean

  • 0 in reply to Andrean С.
    TI__Intellectual 2560 points

    Hi,

    We are verifying with the hardware specialists whether there is an actual problem with the generated assembly or whether the compiler warning is incorrect.  There are some special pipeline behaviors involved with the relevant instructions.  The DIV2PIF32 write of R0H requires 1 less cycle than usual prior to a store to memory (the MOV32 instruction) so the latency between these 2 instructions in the sequence below would ordinarily be correct.  However, the MOV32 is happening in parallel with the MPYF32 which writes R0H, so we need to confirm if the special latency still applies.  We will get back to you as soon as we get a definitive answer from the hardware folks and the bug report will be updated accordingly.

            DIV2PIF32 R0H,R0H               ; [CPU_FPU] |3424|

            MPYF32    R1H,R5H,R3H           ; [CPU_FPU] |3423|

            MPYF32    R0H,R6H,R7H           ; [CPU_FPU] |3423|

    ||      MOV32     *-SP[2],R0H           ; [CPU_FPU] |3424|

    Regards,

    Anna Youssefi

    TI Compiler Support Team

  • 0 in reply to Anna Youssefi
    TI__Guru**** 251020 points

    It will take some time to work out the details of the pipeline behavior with the hardware experts.  Please be patient.

    Thanks and regards,

    -George

  • 0 in reply to Andrean С.
    TI__Intellectual 2560 points

    Dear Andrean,

    We have received confirmation that there is no problem with the assembly sequence because the parallel MOV32 has already read the output register of DIV2PIF32 before the parallel MPYF32 will overwrite it.  Therefore, I have updated the bug report to indicate that the Assembler warning is incorrect in this situation and we will update the Assembler to detect this special circumstance.

    Best,

    Anna Youssefi

    Compiler Support Team

  • 0 in reply to Anna Youssefi
    Prodigy 180 points

    Hello Anna,

    Glad to hear that this is not a bug!

    Thank you very much for your help!

    Best regards,

    Andrean