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.

funny problem with 5515 assembler.



 

 I really think the 5515 MNEMONIC assembler has a problem. It will encode an invalid MPY instruction. Per document spru374g.pdf the instruction is not shown as valid but it does not give an error but it encodes the instruction in error.

 

// Execute these instructions and the last MPY instruction changes T3 even though it's not part of the instruction

MOV     #0,T3

MOV     #0x1111,*AR0

MOV     #0x2222,*AR1

MPY     *AR0,*AR1,AC0

// After the above MPY instruction executes T3==0x1111 so it's as if it's encoded as:

// MPYM T3=*AR0,*AR1,AC0

// The above form of MPY is not allowed per the data sheet, spru374g.pdf, but it does not give an error. MPYM is the correct form.

 

 

// Execute the same sequence with the last instruction MPYM rather than MPY and T3 DOES NOT CHANGE. Here MPYM is the proper form per document spru374g.pdf

MOV     #0,T3

MOV     #0x1111,*AR0

MOV     #0x2222,*AR1

MPYM  *AR0,*AR1,AC0

Then I looked at the above in the disassembly window and sure enough for the first of instructions above I see my source line but the disassembled line shows the "T3=*AR0" part of the instruction. It's an easy TYPO to type MPY rather than MPYM for the above instruction and then all of a suddent T3 is changing on you and your program doesn't work.

And in a completely differnt complaint. This website had all sorts of problem when I tried to used it with WINDOWS 7. Now I'm using XP and it works good.

 

 

 

 

  • The problem here is that the C55x mnemonic assembler accepts not just C55x mnemonics, it also tries to accept C54x mnemonics when possible.  In this case, MPY is not a native C55x mnemonic, but it is a native C54x mnemonic, and that instruction does set the C54x T register (equivalent to C55x T3), so the assembler is correct to encode this as if it were "MPYM T3=*AR0,*AR1,AC0".  I do not know of a way to disable C54x mnemonics, or to warn when they are used.

  • I find your answer sort of frightening (and some you have got to be kidding) because if I accidentally type MPY rather than MPYM the assembler gives no error and T3 is changing at random and it will be next to impossible to find or debug. Now I'm concerned that I have other typo's and instructions that are 54x instructions.

    Ya know assembly programming is hard enough and this shared assembler makes it a lot more challenging because a minor typo and you are screwed.

    I went and looked at the instruction in question on the 54x and I see what it's doing but I'm not happy about it.

    And I think you said that MPY isn't valid in the 55x. Actually it is valid. Instructions that multiply registers like T0, AC0 etc..  use MPY but if SMEM, YMEM are used then MPYM is used. So if I cut and paste MPY T1,AC0,AC1 to MPY *AR0,*AR2,AC2 and I forget the "M" on MPY then T3 will change without the slightest hint and the assembler gives no error.

    Now we need to code review the whole thing to make sure all the instructions are valid 55x instructions and not 54x instructions with unknow side effects like changing T3

     

  • Refer to section 6, pg 169 of the most recent Assembly Language Tools User Guide #spr280i.

    If you generate assembly listing using the --asm_listing when invoking cl55, the file should begin with a comment  e.g. “ Temporary Registers Used: T3” if a temporary reg is used when the 54x instruction is encoded into its equivalent 55x instruction.

    This comment appears only when temporary registers are necessary in the porting of the code.

    I tried generating the assembly listing file.

    In the assembly source file, I used the 54x instruction:  MAC *AR0+, *AR1, AC0

    At the top of the listing file, I expected to see the comment :  ; Temporary Registers Used: T3

    But instead I see: ; Temporary Registers Used: None 

    I expected to see the equivalent 55x instruction line in the listing file: !REG! MACM T3= *AR0+,*AR1, AC0

    But instead I see MAC *AR0+, *AR1, AC0

     

     

    At the least, this feature should work as expected, but it doesn't. Why?

    In future assembler version, there should be a switch option added to the assembler to allow one to disable 54x instruction mnemonics if they so choose.

    Regards,

    Mark

  • Aside: Note that technically MAC *AR0+, *AR1, AC0 is not a valid C54x instruction since the two memory operands have to be dual memory (Xmem, Ymem) operands and indirect dual operands have to use AR2, AR3, AR4 or AR5.  In fact the C54x assembler will reject it.  But apparently we are willing to support the C54x instruction without the C54x dual operand restriction.

    The valid C54x instruction "MAC *AR2+, *AR3, A" is defined to set the T register to *AR2+.  There is an equivalent C55x instruction (the full long form of which is "MACM T3=*AR2+, *AR3,AC0,AC0") so no multi-line expansion is necessary nor is a temporary register needed.  In this case T3 is an operand of the original instruction and is not a temporary.

    The section of the manual you cite (6, pg 169) also says that "C54x instructions with a different syntax in C55x but a single-line mapping also appear without any special notation" so I was not surprised to see the "MAC *AR2+, *AR3, A" repeated in the listing although I think would rather have seen the C55x version.  The listing worked as expected but not necessarily as desired.

     

  • Hi There, I just came across the same issue with MPY. Has this issue being fixed in the newer releases of the tool? This is really misleading since it is not mentioned in any documents for the instruction sets and the fact that there is a status bit in ST1_55 to disable able any association with C54xx (that is on top of setting the Device Family to C5500 in the project property). Also is there a list that includes other discripencies that one should expect due to assmebler assembling code for C54xx? 

  • I apologize for the delay.  Unfortunately, no progress has been made on this issue.

    Thanks and regards,

    -George