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.

ASM checker for TMS320C667x

 Dear team,

My customer would like to have a ASM checker for TMS320C667x with the following capacities:

-          The ASM include file (*.i) shall only contain comment, empty lines or include lines.

-          “.sect” keyword is forbidden inside a macro.

-          All labels shall be placed in column 1 and is followed by a colon (“:”) or a question mark “?”.

-          When using a label inside a macro, the question mark “?” shall be used:

  • instead of the semicolon “:” after the label tag,
  • at the end of the label name when used

-          Registers A0 to A31 and B0 to B31 shall be initialized before being used.

-          Multiple assignments of registers are forbidden

-          Hand-coded register renaming (.asg directive) is forbidden

-          A comment “;#Reserve <register_list>” shall be written before using any register of the A or B register file. When the register is no more used, the comment “;#Free <register_list>” shall be inserted after the last instruction using it. Registers of <register_list> are separated with commas “, ”

-          Unit specifier field (.D1, .D2, .M1, .M2, .L1, .L2, .S1, .S2) shall be specified for all instructions except unitless ones.

-          The output width of .M1/.M2 unit shall not exceed 128 bits per DSP cycle.

-          .L1/.L2 and .S1/.S2 functional units shall not write twice in the same DSP cycle on the same functional unit.

-          Two instructions shall not write to the same register on the same DSP cycle.

-          Fast floating point instructions shall be used instead of old ones, only kept for backward compatibility (FADDSP/FSUBSP instead of ADDSP / SUBSP)

-          Functional unit latency (i.e. the delay during a functional unit is locked before it can start executing the next instruction) shall be respected for all instructions.

-          Branching instructions shall use only labels (no literal constants)

-          Conditional compilation/assembly is forbidden except for #include guards in*.h files when coding in C.

-          MFENCE instruction shall not be executed in parallel with any other instruction.

-          Two instructions using the same functional unit cannot be issued in the same execute packet.

-          All double-precision floating point instructions are forbidden.

-          DINT/RINT instructions are forbidden

Please reply to the post, i will forward him ,

Thanks, Maxime

  • Hi Maxime,

    I've forwarded this to the software experts. Their feedback should be posted here.

    BR
    Tsvetolin Shulev
  • The entry CODEGEN-1926 was added to the SDOWP system to track this request.  It is filed as an enhancement request, and not a bug.  Unfortunately, at the present time enhancement requests like this are not made available for public view.

    Thanks and regards,

    -George

  • George Mock said:
    Unfortunately, at the present time enhancement requests like this are not made available for public view.

    I'm pleased to say I was wrong about that.  You are welcome to track the issue CODEGEN-1926 with the SDOWP link below in my signature.

    Thanks and regards,

    -George

  • George Mock said:
    You are welcome to track the issue CODEGEN-1926 with the SDOWP link below in my signature.

    Since it's titled "Add static checks to the C6000 assembler" I'd like to express concern that making suggested checks obligatory would be counter-productive. Most notably I appreciate very much  that currently assembler doesn't actually require to assign execution port and/or the data path number and does it for you. Well, occasionally it does get it wrong in SPLOOP,s but it's easy to resolve by assigning number-less execution port. Personally I find some of original suggestions unreasonable, as they have "humans for computers" clang. I mean software is supposed to assist humans, not vice versa, and some of suggestions are kind of "vice versa". It should also be noted that some of the checks are actually implemented. For example assembler won't allow you to use same register as destination in same execution packet. Well, for single-cycle instructions, but apparently not for multi-cycle such as floating point ones. In other words there actually is room for improvement. To be frank I feel that development in this direction stopped at some point. Most notably assembler actually is capable of issuing warnings for some of early silicon erratas, which makes you reconsider the code, but it for example doesn't make checks for functional unit latencies...