• Locked Locked
  • Replies 4 replies
  • Subscribers 55 subscribers
  • Views 818 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.

CLA Assembler Incorrect Assembly

Wally Ritchie42594
Intellectual 430 points

CCS 4.1.0.02003  and 28035

The assembler doesn't seem to handle the following correctly and assembles the instruction with an immediate value of 0x0000

 

MUI16TOF32 MR1,*MAR0[(_Symbol1.Tone1Phase-_Symbol1.Tone1Bin)]++

The assembler outputs (without warning or error):

352 000000f0 0000 MUI16TOF32 MR1,*MAR0[(_Symbol1.Tone1Phase-_Symbol1.Tone1Bin)]++

    000000f1 7551 

 

 

Symbol1 is a structure and Tone1Phase and Tone1Bin are members. The difference in their offsets is +1.

The relevant defines as automatically fed to the assembler are:

A 5969 .global _Symbol1

A 5970 _Symbol1 .tag OFDMSYMBOL

and:

A 5071 OFDMSYMBOL .struct 0,1 ; struct size=(8 bytes|128 bits), alignment=1

A 5072 0000 Tone1Bin .field 16 ; unsigned int Tone1Bin - offset 0 bytes, size (1 bytes|16 bits)

A 5073 0001 Tone1Phase .field 16 ; unsigned int Tone1Phase - offset 1 bytes, size (1 bytes|16 bits)

A 5074 0002 Tone2Bin .field 16 ; unsigned int Tone2Bin - offset 2 bytes, size (1 bytes|16 bits)

A 5075 0003 Tone2Phase .field 16 ; unsigned int Tone2Phase - offset 3 bytes, size (1 bytes|16 bits)

A 5076 0004 Tone3Bin .field 16 ; unsigned int Tone3Bin - offset 4 bytes, size (1 bytes|16 bits)

A 5077 0005 Tone3Phase .field 16 ; unsigned int Tone3Phase - offset 5 bytes, size (1 bytes|16 bits)

A 5078 0006 Tone4Bin .field 16 ; unsigned int Tone4Bin - offset 6 bytes, size (1 bytes|16 bits)

A 5079 0007 Tone4Phase .field 16 ; unsigned int Tone4Phase - offset 7 bytes, size (1 bytes|16 bits)

A 5080 0008 .endstruct ; final size=(8 bytes|128 bits)

The indirect increment CLA addressing mode is more powerful than it first looks as it is essentially a parallel load with zero cost. However, if the assembler won't do symbol arithmetic correctly the capability becomes very difficult to use. 

The work around (at least for structures) is to manual assemble constants like we did in ancient times ;)  

  • TI__Guru**** 249260 points

    A workaround is to write this instead ...

    MUI16TOF32 MR1,*MAR0[(OFDMSYMBOL.Tone1Phase-OFDMSYMBOL.Tone1Bin)]++

    Note the use of OFDMSYMBOL instead of _Symbol1.  I'm not sure how this is really supposed to work.  So, I filed record ID SDSCM00035286 in our SDOWP system.  Feel free to track it at the link I give in my sig below.

    Thanks and regards,

    -George

     

  • in reply to George Mock
    Intellectual 430 points

    Thanks George. I can confirm that using the tag name works (as I think it should in the assembler).

    The assembler instruction below has the same issue:

    MUI16TOF32 MR1,*MAR0[(_Symbol2.Tone1Phase-_Symbol..Tone2Bin)]++

    Note that in this case these are two different structure variables. Both are relocable. The assembler incorrectly assembles a non-relocable zero WITHOUT ERROR OR WARNING.

    I haven't found separate documentation on the CLA assembler but assume that it is derived from (or is a version of) the assembler described in spru513c.pdf. Looking into this a bit further it appears that the assembler is requiring a "Well-Defined" expression. So, the bug is that the assembler is not flagging the error that the expression is not well defined.

    That being said, given the format of the assembly instruction (single word full address) and the full address range capabaility of the instruction, there is no reasonable reason to restrict the expression within the brackets to a well-defined expression. A difference of two relocables to be loaded into a single word can normally be handled by the linker, even if the addresses are in different sections, as long as the result fits in 16 bits.

    For applications trying to squeeze out maximum performance, the ability to essentially parallel load an address register with the next address to be used can save many cycles.

    There are probably other work arounds, large structures and absolute addresses, but none that will work well when moving between sections (like different message RAM or SRAMS).

    Thanks for the bug ref. I''ll follow it if I can find a system old enough to be running explorer 5.01 - 6.0 or Netscape 4.72-4.77 ;-)

     

     

  • in reply to Wally Ritchie42594
    TI__Guru**** 249260 points

    Wally Ritchie said:

    The assembler instruction below has the same issue:

    MUI16TOF32 MR1,*MAR0[(_Symbol2.Tone1Phase-_Symbol..Tone2Bin)]++

    Actually this is different enough that filed another entry with id SDSCM00035299 .  

    Wally Ritchie said:
    Thanks for the bug ref. I''ll follow it if I can find a system old enough to be running explorer 5.01 - 6.0 or Netscape 4.72-4.77 ;-)

    I think you're just joking.  In case you aren't ...  I'm not aware of any need to use an old brower to see SDOWP issues.

    Thanks and regards,

    -George

     

  • in reply to George Mock
    TI__Guru**** 162255 points

    I just opened SDOWP on Windows 7 64bi Ultimate using IE8 and Chrome 4.0.  I don't get any error messages.