Compiler

Bug Description

BUG DESCRIPTION
===============
 
When generating code to access memory operands of the form "ptr->mos", and
the evaluation of the operands is "isolated", the compiler may err in the
handling of the jump/label tracking.  This can result in code with incorrect
control flow (jumping to the wrong place, endless loops, etc.).  In this
context, "isolated" means the memory operand is not part of a larger
expression which requires further code to evaluate.  Examples include:
 
        struct s
        {
          int mos;
          ...
        };
 
        struct s *ptr;
        volatile struct s *vptr;
        ...
 
        ptr->mos <0; vptr->mos;
 

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
 Use construct in larger expression or make dummy assignment:
 i.e.
 
     if (ptr->mos > 0);
     dummy = vptr->mos;

Bug Description

BUG DESCRIPTION
===============
 
  When a nested structure is not the first element within
  a structure definition, the optimizer may inadvertently
  calculate incorrect offset for the nested structure
  members.
 
  i.e.
 
  typedef struct
  {   int mem1, mem2; } LEVEL2
 
  typedef struct
  {   int mem3, mem4, mem5;
      LEVEL2 nest;
  } LEVEL1 ;
 
  void func(void)
  {  LEVEL1 *p= (LEVEL1 *) 10000;
     p->nest.mem1 = 1000;  <====== Incorrect code generated p->nest.mem2 = 2000;  <====== to access these members 

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
  1. Make nested structure member first member in parent
  structure definition.
 
  i.e.
 
 
  typedef struct
  { LEVEL2 nest;
    int mem3, mem4, mem5;
  } LEVEL1;
 
 
  2. Compile without optimization.

Bug Description

BUG DESCRIPTION
===============
 
The compiler generates a macro for RPTK that is placed at the
beginning of the generated assembly file. If you insert an
asm statement in the C source code that uses the repeat instruction
this gets replaced by the macro and can lead to errors at assemble
time.
 
i.e.  main()
      {
             asm(" rpt #1");
 
 
 
      Results in assembler error
 
      19 0000 0001    rpt  #1
 *********  WARNING - TRAILING OPERAND(S)
 

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
Problem will be fixed with next release.

Bug Description

BUG DESCRIPTION
===============
 
Given the expression
 
        (s.bf2 & POW2)
 
where "s.bf2" is a bit field in a structure which is *not* the first member
of that structure, and "POW2" is a power of 2, the compiler generates
incorrect code when such expressions are used for conditional branches.
Conditional branches include "if" statements, "while" and "for" loops,
operands of "&&" and "||", etc.  For example:
 
        struct fields
        {
          unsigned bf1 : 4;
          unsigned bf2 : 4;
        } s;
 
        ...
 
        if (s.bf2 & 8)  /* generates incorrect code */

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
Assign the expression to temporary or change the definition
of the structure to declare that member of the structure first.
 

Bug Description

BUG DESCRIPTION
===============
 
Using the shell command line option "-rAR6" or "-rAR7" to simply inform the
compiler not to use those registers works fine.  However, actually declaring
a global register variable
 
        register int AR7;       /* declared at file level scope */
 
does not work.  The compiler incorrectly saves/restores the register in
every function in the file.  It should not be modifying the register except
when the user makes a reference to it.

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
There currently is no workaround for this problem. It
will be fixed in the next release.

Bug Description

BUG DESCRIPTION
===============
 
The compiler errs in generating code to save/restore global
registers AR6/AR7 on entrance/exit from a function even though
these have been declared as register variables. In addition, it
may generate incorrect code when restoring the register values
on exit from the function. Causing incorrect values to be placed
in the register.

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
None specified at this time. Will fix next release.

Bug Description

BUG DESCRIPTION
===============
 
The compiler "tracks" values in the accumulator, so that it detect cases
where a memory value is already in the accumulator and therefore doesn't
need to be loaded.  For example:
 
        a = b + c;      /* result ends up in accumulator and 'a' */
        d = a;          /* instead of loading 'a', copy accumulator to 'd' */
 
When an assignment from a I/O port is made:
 
        a = port5;
 
the compiler fails to note that 'a' should no longer be tracked in the accumu-
lator.  So, for instance
 
        a = b + c;      /* result ends up in accumulator and 'a'             */
        a = port5;      /* 'a' is overwritten, but compiler still tracks 'a' */
                        /* in the accumulator                                */
        call(a);        /* BUG!  Instead of loading 'a' from memory, copies  */
                        /* the accumulator to the stack instead              */
 

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
No workaround available. Problem will be fixed in next release.

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
Problem will be fixed in next release.

Bug Description

The compiler may err when performing comparing two "long" expressions.
When checking for overflow condition on the results of the compare
it inadvertently resets the overflow bit, causing incorrect branch
to be taken.
 
i.e.
 
        long var1,var2;
 
        .
        .
        if ( var1 > -var2)    

Bug Description

BUG DESCRIPTION
===============
 
When handling this expression ...
 
        [memory operand] << [constant expression], [anything] the compiler may crash. For example: int i,j; i<<1, j++; 

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
Compile with optimization.

Bug Description

BUG DESCRIPTION
===============
 
The optimizer pass of the compiler may decide to allocate user local variables
to AR registers rather than locations on the stack frame.  Similarly, it may
create temporary variables which reside in AR registers rather than memory.
If this circumstance combines with an assignment from a port location,
the compiler doesn't handle it.  Instead it emits the internal error message:
 
        COMPILER ERROR: something wrong in port_asg!!!
 
For example ...
 
        
 
when compiled "dspcl -v2xx -o " has this error.
 
v2xx -x2 -o3 -op0 -k -s -n  file.c
 

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
  Do not compile with optimization.

Bug Description

BUG DESCRIPTION
===============
 
Any time the compiler sees an expression of the form ...
 
        *++ = 
 
and you compile with -v50, the post-increment on the pointer doesn't occur.
The pointer must be to a 16-bit integer type.  The bitwise operations are
&=, |=, ^=.  So, for example ...
 
        unsigned *p1;
        *p1++ &= 0xfffe;
 

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
 Compile with -v25  -n options to create the assembly file only.
Then assemble with -v50 option. Or increment the pointer in a
separate expression.

Bug Description

BUG DESCRIPTION
===============
When handling a comparison of the form...
 
  (  CONSTANT)
 
  i.e.   long i;
 
          if (i <= 1800000) the compiler erroneously does the comprison by negating the constant and then adding rather than doing a subtract. However, the sequence of branch instructions which follow the comparison presume the use of subtract instructions. Add instructions do not set the status bits as those branch instructions expect. 

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
Problem is fixed for next release.
 

Bug Description

BUG DESCRIPTION
===============
 
The compiler handles "fabs" function calls not by calling that function,
but by directly generating code for it.  It didn't handle the case of
"fabs()".
 
i.e.
 
void main(void)
{
        float a,b;
 
        a = b = 4.0;
        a = fabs(sqrt(b));  Result of sqrt is in accumulator
        a = sqrt(a);
}

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
    Use temporary variable to hold expression before calling fabs.
 
    i.e.
 
     tmp = sqrt(b);
     a = fabs(tmp);
 
 

Bug Description

BUG DESCRIPTION
===============
 
There is a bug in the handling of the .blong directive when it occurs
near a page boundary. If the value of the current section program
counter, pc,  is either xx7d or xx7f when a .blong directive is
encountered, a pass conflict error will occur.

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
Rearrange the data so that longs will not span a page boundary.

Bug Description

BUG DESCRIPTION
===============
 
When a MEMORY directive defines memory ranges that overlap, the linker
correctly emits an error message, but may err in reporting the names of
the overlapping memory ranges.

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
Carefully check MEMORY directive in linker command file to
locate overlapping memory ranges, then adjust the lengths
of the offending memory range so that the ranges no longer
overlap.

Bug Description

BUG DESCRIPTION
===============
 
  V6.60 linker fails to link object code that is the
  result of a previous link in which the symbols have
  been stripped from the object file. It will give
  the fatal error message
 
  "fail to read string table of file ...

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
  The problem is caused by the fact that the because the
  symbol table size is zero, the pointer to the start
  is interpreted to be the first 4 bytes of the COFF
  header. In the string table, the first 4 bytes contain
  the size of the table. The linker attempts to read that
  many bytes from the file. The workaround therefore is to
  increase the size of the object file so it contains at
  least that number of bytes.
 
  The simplest method is probably just to append zeroes
  to the end of the object file until it reaches a size
  where the linker error message is not longer given.

Bug Description

BUG DESCRIPTION
===============
 
The hex conversion utility, DSPHEX, failed to recognize
2xx as valid processor version for generating boot table
and consequently would not generate boot header for COFF
objects generated when -v2xx option is selected for
compile/assemble.

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
Will be fixed in next release.

Bug Description

BUG DESCRIPTION
===============
 
    The code for the copy of the .const section within the C boot
routine c_int0, for the C2x and C2xx devices can only copy a maximum
of 256 words. If the length of the .const section is larger than
256 then only the length mod 256 (length % 256) number of items are
transferred.
 
    The problem is caused by use of the RPT to iterate the BLKP
instruction for transferring the data. Since RPT counter register
is only an 8-bit counter on the C2x/C2xx, this restricts the number
of items that can be transferred.

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
Extract boot.asm from your rts.src:
 
        dspar -x rts.src boot.asm
 
Perform the following edits.  Replace this code:
 
****************************************************************************
* CONST COPY ROUTINE - COPIES THE .const SECTION FROM PROGRAM TO DATA MEMORY
****************************************************************************
        .if CONST_COPY
const_copy:
 
****************************************************************************
* C2x/C2xx VERSION - MUST USE 'RPT *' BECAUSE RPTK COUNT ISN'T BIG ENOUGH
****************************************************************************
        .if     .tms32025 | .tms3202xx
        LALK    #__const_length         ; load length of const section
        BZ      quit                    ; if 0, quit
        LRLK    AR2,#__const_run        ; AR2 = const address in data
        LALK    #__const_length-1       ; load length - 1
        SACL    *                       ; write to temp
 
        RPT     *,AR2                   ; repeat length times
        BLKP    #__const_load,*+        ; block copy from program
 
        LARP    AR1                     ; restore ARP to SP
quit:
        RET                             ; return
        .endif ; .tms32025 | .tms3202xx
 
With the following code:
 
****************************************************************************
* CONST COPY ROUTINE - COPIES THE .const SECTION FROM PROGRAM TO DATA MEMORY
****************************************************************************
        .if CONST_COPY
const_copy:
 
****************************************************************************
* C2x/C2xx VERSION - CAN'T USE RPT.  COUNTER IS ONLY 8-BITS WIDE
****************************************************************************
        .if     .tms32025 | .tms3202xx
        LARP    AR3
        LRLK    AR3,#__const_length     ; AR3 = length of section
        BANZ    cont,*-,AR2             ; Check for zero and decrement
        B       quit                    ; if (zero) quit
cont:
        LRLK    AR2,#__const_run        ; AR2 = const address in data
        LALK    #__const_load           ; ACC = const address in program
cloop:
        TBLR    *+,AR3                  ; copy from program to data
        ADDK    1                       ; increment program address
        BANZ    cloop,*-,AR2            ; check for zero and decrement
quit:
        LARP    AR1                     ; restore ARP to SP
        RET                             ; return
        .endif ; .tms32025 | .tms3202xx
 
Assemble the new boot.asm:
 
        dspa -v2xx boot.asm  OR  dspa -v25 boot.asm
 
Archive into the object library:
 
        dspar -r rts2xx.lib boot.obj  OR  dspar -r rts25.lib boot.obj
 
The C50 is unaffected by this bug.  Don't forget the source library:
 
        dspar -r rts.src boot.asm

Bug Description

BUG DESCRIPTION
===============
 
  The example C program shown on pg 1-26 of the  TMS320C1x/2x/2xx/C5x
Code Generation Tools (Release 6.60) Getting Started Guide, shows
incorrect C syntax. This program will not compile correctly as written.
 
e.g.
 
     /*************************************************************/
     /*                       function.c                          */
     /*              (Sample file for walkthrough)                */
     /*************************************************************/
 
     main()
     {
          int x = -3             <===== Statement missing closing ";" X="abs_func(X)" <="====" Statement missing closing ";" } <="====" Note: Symbol "X" should be "x" int abs_func(int i) int i; <="====" Mix of old K&R and ANSI style func def { int temp="i;" if (temp < 0) temp *="-1;" return (temp); } 

Workaround/Solution

WORKAROUND/SOLUTION
===================
 
A corrected version of the program is shown below:
 
      /************************************************/
      /*                 function.c                   */
      /*          (Sample file for walkthrough        */
      /************************************************/
 
      main()
      {
          int x = -3;
          x = abs_func(x);
      }
      int abs_func(int i)
      {
            int temp = i;
            if (temp <0) temp *="-1;" return (temp); } 

Bug Description

BUG DESCRIPTION
===============
 

Workaround/Solution

WORKAROUND/SOLUTION
===================