EMULATION PORTING KIT (C50) 7.20

EMULATION PORTING KIT (C25) 6.40

COMPILER 6.60

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;
 

BUG DESCRIPTION
===============
 
  When a nested structure is not the first element within
  a structure defnition, 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

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)
 

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 */

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.

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.

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              */
 

The compiler may err when performing comparing two "long" expressions.
Problem: compares between 2 variables of type 'long' does not work correctly.
 
When checking for overflow condition on the results of the compare
it inadvertently resets the oveflow bit, causing incorrect branch
to be taken.
 
i.e.
 
        long var1,var2;
 
        .
        .
        if ( var1 > -var2)    < incorrect branch may be taken for this
                                expression
 
 
 
NOTE: There is another bug similar to this, SDSsq05116, but it
involves comapres between a constant and a variable both of type
'unsigned long'. This bug was filed against V6.65 compiler.
This will be fixed in the next official release. (4'th quarter '98).

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

BUG DESCRIPTION
===============
 
Whenever the compiler uses the instructions "BLKD" or "BLDD" to copy between
memory locations, it fails to adjust its internal tables to note that the
destination memory location just written cannot continue to be tracked as
a value held in the accumulator.  A later reference to the memory location
may result in the incorrect use of the accumulator rather than loading
the memory location.
 
Glossing over some knotty detail here ... The instructions "BLKD" and "BLDD"
handle assignments between scalars (not arrays or structures) when one or both
operands is a global or static variable.  Some examples ...
 
        int global1, global2;
 
        void func()
        {
            int local1, local2;
            int *p1, *p2;
 
            /* These are handled with BLKD/BLDD     */
 
            global1 = global2;
            global1 = local1;
            *p1     = global1;
 
            /* These are NOT handled with BLKD/BLDD */
 
            *p1 = *p2;
            local1 = local2;
            *p1 = local1;
        }
 
An example of the bug ...
 
        int g1, g2, g3;
 
        void func()
        {
            int local;
 
            local = g1 + 10;
 
            /* The compiler tracks "local" in the accumulator */
 
            local = g2;
 
            /* The compiler uses BLKD to do the assignment.  It fails to    */
            /* change its internal tables to note the value in "local" is   */
            /* now different from that in the accumulator.                  */
 
            g3 = local;
 
            /* Rather than loading "local" from memory, it copies the       */
            /* accmulator to "g3"                                           */
        }

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
 

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;
 

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.
 

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);
}

When doing a signed divide and the divisor is a compile constant
that is a power of 2 (such as 32), the compiler implements the
divide as an arithmetic shift.  This would be okay for unsigned
numbers but not for negative signed numbers.
 
For example the code
 
 volatile short v1 = -33;
 volatile short v2;
 
 v2 = v1 / 32;
 
 /* v2 is now set to -2, should be -1 */
 
The problem exists for dividing long signed integers as well.

BUG DESCRIPTION
===============
The compiler sometimes does not execute conditional blocks correctly.
When dpscl is used to compile and assembly file, it sometimes
branches to the wrong block of code.
 
Consider the following piece of code: (test.asm)
 
        .if     $isdefed("E_DBUG")
        hvdskklsa_is_defed               ;will cause an error
        .else
        lksjdb_isnot_defed                 ;will cause an error
        .endif
 
If this is compiled with : dspcl test.asm -dE_DBUG
it branches to the 'else' part of the code, which is not correct.
 
 PASS 1
 PASS 2
        lksjdb_isnot_defed
"dspinit.asm", line 4:  INVALID OPCODE
 
However, if dspa is used it branches to the correct block
(in this case the 'if' block).
 
If assembled with : dspa test.asm -dE_DBUG
it branches correctly to the 'if' part of the code.
 PASS 1
 PASS 2
        hvdskklsa_is_defed
"dspinit.asm", line 2:  INVALID OPCODE
 
 
NOTE: here "hvdskklsa_is_defed" and "lksjdb_isnot_defed" is just
some garbage.

BUG DESCRIPTION
===============
Compiler hangs while compiling the following peice of code:
 
file: t.c
Command line: dspcl t.c
 
void main(void)
{ int i;
  for(; ;)
    { for(i=0;i<10;i++)
          { if(i>5)
                goto label;
           }
       label:goto label;
     }
}
 
 

The compiler with the optimizer generates a CALLD followed by
a 1-word instruction and a 2 word OUT instruction which does
not work correctly.
 
This occurs after an ioport access.  Adding a assembly insert
NOP after the ioport access solves the problem.
 
     asm(" nop");
 
You can also compile using a different optimization level.

C SOURCE INTERLIST 6.60

ASSEMBLER 6.60

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.

The TMS320C1x/C2x/C2xx/C5x COFF Assembler, Version 6.60 won't allow the
use of a substitution symbol to shorten long structure references.
 
Following is an example:
.asg    "pg_struct.B_record.elemC",xxx
        .asg    "pg_struct.B_record",B_rec
 
        lacl    pg_struct.B_record.elemC
 
        lacl    xxx
 
        lacl    B_rec.elemC
 
The following are valid pg_struct.B_record.elemC and xxx.
 
This is not valid B_rec.elemC. Produces an error message, Expression not terminalted properly.
You cannot reference an element of the structure that is a long refernce that is used in the same instruction.
 
 
 
 

LINKER 6.60

ARCHIVER 6.60

HEX CONVERTER 6.60

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.

ABSOLUTE LISTER 6.60

XREF UTILITY 6.60

LIBRARY BUILDER 6.60

RTS 6.60

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.

If the FTOU library routine takes the OVERFLOW path, then the
stack is not restored properly.  Registers indicate that the
stack has one more element than it should. So, the calling
routine then returns improperly when it gets to its RET.
 

Due to the 16-bit integer implementation, attempts to use the
time and date functions will sometimes give erroneous results.
Affected functions include but are not necessarily limited to:
 
                gmtime()
                localtime()
                ctime()
 

DOCUMENTATION 6.60

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 progrma 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);
    }
 

DEBUGGER 6.60

PDM 7.20

C5X SIMULATOR 1.30

C5X EMULATOR 7.20,7.40

C2X SIMULATOR 3.00

C2X EMULATOR 6.40

C1X SIMULATOR 2.00

C2XX SIMULATOR 1.30

BUG DESCRIPTION
===============
 
   The simulator does not allow patch assembly of SETC or CLRC
instructions.
 

C2XX EMULATOR 1.00

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

EMULATION PORTING KIT (C50) 7.20

EMULATION PORTING KIT (C25) 6.40