Bug Description

BUG DESCRIPTION
===============
The following ISR does not save AR0 even though
it modifies it.  This is a problem with V4.60 and
V4.70.
 
void *a;
 
typedef struct
{
  int v;
}M;
 
typedef struct
{
   M m;
} dd;
 
dd D[2];
 
/* workaround()
{
} */
 
void c_int01(void)
{
  M t;
/*  workaround(); */
  D[1].m = t;
  a = &D;
}
 

Bug Description

When the -g option is used with asm30 or cl30 for assembly files, the
assembler places debug information in the COFF file that makes the C3x
Debugger V5.00 and the C4x Debugger V2.40 fail.

Bug Description

The optimizer does not recognize the -v32 or -v44 option.  This is true
even when the shell, cl30, calls the optimizer, opt30.

Bug Description

The shell, cl30, will give a "out of memory" error if it is called without
a source file on the command line (for example: cl30 -z c30.cmd).  This is
only a problem with the DOS versions.

Bug Description

BUG DESCRIPTION
===============
The compiler produces incorrect code for the following C code
when the following command line is used:  cl30 -sn bug.c
It does not correctly dereference a struct ptr to a float
member that is casted to a int pointer.
 
typedef struct
{
  float f;
  int i;
} A;
 
/* Here is the bug */
 
bug(A *a, int *ptr)
{
   ptr[1] = *(int *)&a->f;
   /* The bug goes away if -o2 is used */
}
 
The code produces the following:
;>>>>      ptr[1] = *(int *)&a->f;
        LDI     *-FP(2),AR0
        LDI     *-FP(3),AR1
        LDF     *AR0,R0
        STI     R0,*+AR1(1)
 
It should produce this:
;>>>>      ptr[1] = *(int *)&a->f;
        LDI     *-FP(2),AR0
        LDI     *-FP(3),AR1
        LDI     *AR0,R0
        STI     R0,*+AR1(1)

Bug Description

BUG DESCRIPTION
===============
 
The optimizer incorrectly calculated an address while folding a loop.

Bug Description

BUG DESCRIPTION
===============
 
The code example exhibits an error when compiling only on the PC version of
the 4.70 copiler.  The following command line was used to reproduce
the error.
 
cl30 -s -v30 -c -mb -d_C30 -x -o2 -on1 -mn -i. -D_C30 cut4.c
 

Copyright (c) 1987-1996  Texas Instruments Incorporated
   "cut4.c"   ==> MeasurementMenu
   "cut4.c"   ==> EditEngravingChannelParam
TMS320C3x/4x ANSI C Optimizer  Version 4.70
Copyright (c) 1987-1996  Texas Instruments Incorporated
   "cut4.c"   ==> MeasurementMenu
   "cut4.c"   ==> EditEngravingChannelParam
TMS320C3x/4x C Code Generator  Version 4.70
Copyright (c) 1987-1996  Texas Instruments Incorporated
   "cut4.c"   ==> MeasurementMenu
>> "cut4.c", line 230: COMPILER ERROR: BAD TREE NODE: 82a09dfc, 32

Bug Description

BUG DESCRIPTION
===============
 
Compiler generates incorrect code for floating point structure member.

Bug Description

Problem:
The ST Flags are Corrupted upon a function call, or ISR.
The following code Fragment is the compiler's generated assembly Return code.
was Generated by version 4.7 CL30, only when the -G option is specified.
 
    pop  ST    ; Pop all the ST flags
    subi 2,SP  ; Modify's the ST flags.
    pop  AR3   ; Modify the  ST flags.
    reti
 
The Compiler should be pushing and popping ST first and last,
in order to preserve the ST Flags.
 
The Problem Can Exist with Function calls or ISR, on Version 4.7 and earlier when -g specified.
Problem has been fixed in version 5.0 CL30
This will only be a problem, if a compare is made before the call,
or when a IRQ is recognized, just after a Compare Instruction, and followed by a Branch
 
              CMPI AR0,AR6   ;  The ST Flags will be set accordingly.
--> IRQ jump
              BNZD           ; Branch is Taking, based on Corrupt Z flag
 
Workaround: None.
 
 
 
 

Bug Description

The compiler is ignoring the -gsrev option detailed on page
13-8 of the 1997 C3x user's guide.
 
The option is not -gsrev, and the correct option -msrev is
not correctly handled.  See the fix info for full details.
 

Bug Description

Sample code:
------------------------------------------------------------------------------
typedef struct {unsigned int wolf:1;} DK;
 
DK *pd;
void dcv(void)
{
    if (pd->wolf = 1);
}
------------------------------------------------------------------------------
 
This code generates an internal compiler message:
 
cl30 dcv.c
[dcv.c]
TMS320C3x/4x ANSI C Compiler            Version 5.00
Copyright (c) 1987-1997 Texas Instruments Incorporated
   "dcv.c"   ==> dcv
TMS320C3x/4x ANSI C Code Generator      Version 5.00
Copyright (c) 1987-1997 Texas Instruments Incorporated
   "dcv.c"   ==> dcv
>> "dcv.c", line 10: COMPILER ERROR: Decomposition error
 

Bug Description

There is a design flaw in the internal method for choosing
instructions, which makes the TSTB instruction look like an
AND instruction rather than a compare instruction (which compares
AND a,b to zero).

Bug Description

While the parser is correctly catching most cases such as
this, the codegen will sometimes output negative .line
directives if the body of a function uses #line
pragmas to place it before the header of the function.
 
The example below will generate a .line -5 for the expression
in the function body.
 
#line 100
void fred(void)
{
#line 94
        a = 2;
}

Bug Description

The codegen is generating an internal error ("COMPILER ERROR")
for the sample code.  An internal state has reached a
known, but unsupported, value.

Bug Description

The optimizer is incorrectly calculating the offset of the
element inside the inner loop.

Bug Description

The codegen is stripping the circular buffer character '%'
from the user assembly inserted into C source code, resulting
in incorrect assembly when assembly occurs.
 
A workaround is to specify %% instead of just % in the
inline asm code.
 

Bug Description

The runtime function strftime could display the year incorrectly
for a date past the year 1999. The year field will contain
3 digits such as 101, instead of 01 for the year 2001. This
could occur in calls to strftime().
 
 
 
 

Bug Description

When using register passing model, the c30 V5.00 compiler
will generate invalid offsets to variables in arrays.
 
The compiler will generate code that will erroneously add an
offset to itself to calculate an address which will either
result in an access to an invalid memory location or
unconfigured memory.
 
 

Bug Description

Compiler is allocating incorrect registers during allocation
on the C40, including RS, RC & RE during ISRs.

Bug Description

Compiler sometimes incorrectly generates a call to MOD_I40
instead of MOD_U40 when doing a modulo operation on two unsigned
numbers.
 
The problem only seems to occur when a pointer is cast to an
unsigned type; the compiler works correctly for non-pointer
unsigned types.

Bug Description

Bug Description

The compiler is not recognizing that it is quicker to do
a multiply by the reciprocal of a constant rather than
calling the DIV routine.

Bug Description

The compiler is creating illegal code of the form
 
        ldi *+ar1(256),Rx
 
when loading 40 bit long double values.  (An offset of
256 is too large.)
 
There is no known workaround.
 

Bug Description

It appears the v5.0 code generator does not check that the
second 32-bit float of a long double variable is greater
than 256 into the local data set.   Therefore it optimizes
for indirect accessing, which is fine for the first 32-bit
word (i.e. index 255) but is not for the second (index 256).
 
This gives the following error:
 
> TMS320C3x/4x COFF Assembler             Version 5.00
> Copyright (c) 1987-1997 Texas Instruments Incorporated
>  PASS 1
>  PASS 2
>         ldiu      *+ar1(256),r1         ; 40b float lo half
> "code.asm", line 95:  INDIRECT DISPLACEMENT OUT OF BOUNDS
>
>  1 Error,  No Warnings
>
> Errors in source - Assembler Aborted
 
Workarounds are to rearrange the variable declarations or to
declare the problem variables as volatile.

Bug Description

The compiler is generate illegal addressing modes for
the TSTB instruction on the C3x.

Bug Description

The delayed branch optimization option in the v5.0 compiler
( -mp) does not always work.

Bug Description

Compiler is incorrectly using the RS register within
a repeat block, potentially causing premature loop
returns.

Bug Description

Using the frieee() intrinsic function for the C40 causes
a COMPILER ERROR/INTERNAL ERROR

Bug Description

Compiler gives the error: COMPILER ERROR: no match for VARADDR

Bug Description

Compiling with -o3 generates infinite loops, where non-constant
calls to functions have been removed to outside the loop.

Bug Description

When forming a RTPS loop, the compiler's code will always
execute at least two times, even when the original iteration
count is 1.

Bug Description

MPY_LD, DIV_LD, and INV_LD do not properly preserve registers

Bug Description

Compiler is rounding some floats towards
zero, even when -mc flag is used.

Bug Description

The message inside the asm file regarding the global
configuration of the float-to-int flag at compile time is
not reporting it's state correctly.

Bug Description

When using the large memory model, the data page pointer is not
loaded prior to loading a far call address. The DP is correctly
loaded prior to loading a variable, but not loaded prior to
loading the address of a function.

Bug Description

BUG DESCRIPTION
===============
 
The optimizer incorrectly allows memcpy to use rptb/rpts within
repeat loops.

Bug Description

The optimizer incorrectly allows memcpy to use rptb/rpts within
repeat loops. Additionally, structure copies of exactly 5 words
inside a loop might also cause this exact problem.

Bug Description

BUG DESCRIPTION
===============
 
The assembler gives cryptic error message:
 
"filename", line xx:  PORTS MUST BE PREDEFINED FOR THIS INSTRUCTION
 
when R11 is improperly used in a parallel MPYF3 || STF instruction.
 
i.e.      mpfy3 *ar1++(1)%, r6, r11
       || stf   r11, *aro++(1)
 
The proper error message should have been:
 
"filename", line xx: EXTENDED REGISTER R0 - R7 REQUIRED

Bug Description

In the V5.00 compiler, for a MPYF3||SUBF3 instruction,
the assembler will incorrectly encode the operands on the
SUBF3 if they take the form indirect,register,register.
It seems the assembler will only encode the operands in
parallel addressing mode 0x01, and will not encode parallel
addressing mode 0x11.
 
Hence,
 
   MPYF3 *AR0,R1,R1
|| SUBF3 *AR1,R3,R2
 
will be incorrectly encoded as 0x858bc0c1.
 

Bug Description

Bug Description

When compiling the sample code with the -mf option, the
X*4 becomes X*0 in the resulting assembly, even though the
optimizer comments are correct.

Bug Description

The assembler is encoding operands for MPYF3 || ADDF3 contrary
to the form specified in the User's Guide.

Bug Description

IDLE instuction code is produced when IDLE2 instruction is
assembled.

Bug Description

Tools: V5.0
Silicone ID: 2.1
 
When an Add/Float instruction is preformed, the result is
incorrect. ADDF problem only occurs when the DST starts as a
negative number.
Example:
     ADDF 20000000, -.02     results 1.9999998 x10^7

Bug Description

BUG DESCRIPTION
===============
 
The linker core dumps when the fill directive is used.

Bug Description

When any PC tools are used to link one or more object files
which, together, contain no relocatable symbols, an internal
error is generated which says the tool ran out of memory.
 
There is no workaround, other than to link with another
object file which contains a useless relocatable symbol.
 

Bug Description

BUG DESCRIPTION
===============
 
Under some situations after using the -cr (RAM initialization - initialization
by loader) option with the Linker, hex30 will fail to specify to stdout and
the hex30 map file that the .cinit section is being placed in the hex output.

Bug Description

BUG DESCRIPTION
===============
 
Hex utility reports an error when -cr option is used.

Bug Description

The hex utility is not calculating byte offsets correctly for all
memory and rom widths.

Bug Description

BUG DESCRIPTION
===============
 
This is a documentation bug in the TMS320C4x Parallel Runtime Support
Library User's Guide. Pg 4-64 describes the function install_int_vector
to be :
 
        void install_int_vector(void *isr, int N);
 
 
This has changed in v4.7. The file prts40.src in v4.7 has it defined as
 
        typedef void (*ISR_FnPtr)(void);
        void  install_int_vector(ISR_FnPtr ISRFnPtr, int N);
 
 
The correct syntax for using it in the customer's code, is
 
        install_int_vector ((ISR_FnPtr) c_int04, 0x04);
 
 
 

Bug Description

The DIV_F40 routine will sometimes return answers
which are less precise than they could be due to noise
in the lower bits of the floating point register.
 
For example, the following code will print a value that is
not quite 1.0 because of this.
 
#include 
main()
{
    double i=100.0,j=100.0,k;
    k=i/j;
    printf("k = %f\n", k);
    for(;;) ;
}

Bug Description

The RTS has some errors/nuisances.

Bug Description

The function ltoa() is not prototyped in any RTS header file,
and the user thinks it should be according to ANSI's need to
have all functions prototyped.
 
However, ltoa is a non-ANSI, non-standard routine, used
internally by other portions of the library.  Users should use
sprintf(), which is an ANSI function.  If users still want to
use ltoa(), they will need to declare it themselves.
 
 

Bug Description

BUG DESCRIPTION
===============
The disp command gives incorrect results for structure bit fields.

Bug Description

BUG DESCRIPTION
===============
The OSC (Oscilloscope) application demo that used to ship with the EVM and
is now available on the BBS does not work properly when compiled with V4.60
of the C Compiler/Assembler/Linker.

Bug Description

BUG DESCRIPTION
===============
When loading the symbol table (sload or load) of a large COFF file, V5.00
of the Windows XDS510 and EVM Debuggers give a GP Fault error message.

Bug Description

BUG DESCRIPTION
===============
The command "run 1" does not work correctly with a RPTS instruction
with V5.00 of the C3x EVM and XDS510 Debuggers.

Bug Description

The debugger watch window does not display the function arguments
correctly, when a function call is made using the register argument
runtime model:
 
The code below executes correctly, but if a break point is put in the
add_args() function and the variables a1 thru a10 are put in a watch
window, then a1 thru a6 which were passed in registers AR2, R2, R3, RC,
RS, and RE are displayed correctly, but the values for a7 thru a10 are
displayed as follows:
a7 -> 0x002FF81D    a8 -> 7     a9 -> 8     a10 -> 9
 
NOTE: The value displayed for a7 is the return address after the
call to add_args()!
 
 
/* Function prototype */
int add_args(int a1, int a2, int a3, int a4, int a5,  int a6, int a7, int a8,
             int a9, int a10);
 
main()
{
    int i1, i2, i3, i4, i5, i6, i7, i8, i9, i10;
    int result;
 
    /* Initialize variables */
    result = 0;
    i1 = 1;
    i2 = 2;
    i3 = 3;
    i4 = 4;
    i5 = 5;
    i6 = 6;
    i7 = 7;
    i8 = 8;
    i9 = 9;
    i10 = 10;
 
    /* Important point to note:  i1 thru i6 will be passed in registers,
    ** i7 thru i10 will be passed on the stack. */
    result = add_args(i1, i2, i3, i4, i5, i6, i7, i8, i9, i10);
 
    /* BREAK POINT on return statement below.  WATCH result.  It will contain
    ** a 55 as expected.  Code ran correctly, but values of WATCH on
    ** a7 thru a10 were in add_args() function were wrong.
    */
    return;
}
 
 
/*
** Value displayed for a7 will be garbage, value displayed for a8 will be what
** was expected for a7, ....... value displayed for a10 will be what was
** expected for a9.
*/
int add_args(int a1, int a2, int a3, int a4, int a5, int a6, int a7, int a8,
             int a9, int a10)
{
    int j1, j2, j3, j4, j5, j6, j7, j8, j9, j10, sum, sum1;
 
    sum = 0;
    sum1 =0;
 
    /* Put a BREAK POINT at the line above.
    ** Using your debugger, WATCH  a1 thru a10 in a watch window.
    ** Expect WATCH window values for a1 thru a10 to be 1, 2, ... 10 as passed
    ** in call to function.
    **
    ** a1 thru a6 will watch values will be 1, 2, ...6.  GOOD so far!
    ** a7 watch value will be junk!     BAD BUG
    ** a8 watch value will be 7.        BAD BUG
    ** a9 watch value will be 8.        BAD BUG
    ** a10 watch value will be 9.       BAD BUG
    **
    */
 
    /* Copy arguments to local variables */
    j1 = a1;
    j2 = a2;
    j3 = a3;
    j4 = a4;
    j5 = a5;
    j6 = a6;
    j7 = a7;
    j8 = a8;
    j9 = a9;
    j10 = a10;
 
    /* Put a BREAK POINT at following line and watch j1 thru j10.  Correct
    ** values 1 thru 10 will be displayed.  GOOD.
    */
 
    sum = j1 + j2 + j3 + j4 + j5 + j6 + j7 + j8 + j9 + j10;
    sum1 = a1 + a2 + a3 + a4 + a5 + a6 + a7 + a8 + a9 + a10;
 
    /* Put a BREAK POINT on return statement below.
    ** WATCH sum and sum1, both will contain the correct value
    ** 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 = 55
    */
    return sum1;
}
 

Bug Description

The OS/2 version of v2.5 C4x emulator may not work with Rev 5
C40 silicon. The emulator may give a 'target error' message.

Bug Description

When you try to use patch assembly on the OS/2, DOS32, or sun4
version of the c4x emulator to insert a NOP, the emulator gives
an error that a NOP requires a src operand.  The src operand is
optional in a NOP.
 
nop
   ^
ERROR : OPERAND MISSING
 
Workarounds are to use:
 
1) ? *0xaddress = 0x0c800000    ; adds NOP at address.
 
2) Go to memory window and change value at address to 0x0c80000

Bug Description

BUG DESCRIPTION
===============
spru053b TMS320C3x C Source Debugger User's Guide
 
P5-15   mc 0x808048,xdat,WRITE
        mc 0x80804C,rdat,READ
        should read:
        mc 0x808048,rdat,WRITE
        mc 0X80804C,xdat,READ
 
P5-18   pinc myfile,int2
        should read:
        pinc int2,myfile
 
P11-25  Need to add new type field: TX (memory may contain code)
 

Bug Description

BUG DESCRIPTION
===============
When using the -x option with asm30 or the -ax option with cl30, a COPY
section with the cross reference information is included in the COFF file.
Although the COPY section is not supposed to be loaded, TI loaders with core
debugger versions older than 3.33 will attempt to load the section (Using
"version+" on the debugger command line will tell you the debugger core
version).  The C3x Simulator V2.20 loader has the problem and the C4x Simulator
V1.30/V1.31 has the problem.  The following loaders do NOT have the problem:
C4x XDS510/XDS510WS Debugger V2.40 and C3x XDS510/XDS510WS Debugger V5.00.

Bug Description

BUG DESCRIPTION
===============
A simulator bug is causing the following code to ignore all interrupts:
 
L2:     BD      L2
        LDI     *+FP(2),R0
        NOP
        STI     R0,*+FP(1)
 
The code should disable interrupts until the delayed branch completes, but
when it branches back to itself it should be checking for new interrupts and
it is not.  If you do not idle in a loop with a delayed branch, the simulator
does not have this problem.

Bug Description

BUG DESCRIPTION
===============
The 1993 C Source Debugger User's Guide states that when using the file
command, you can use the D_SRC environment variable, -i option or use
command to specify the path (P6-11).  This is misleading.
 
If the -g option is used with the compiler, the COFF file will contain
debugger information.  When this COFF file is loaded into the Simulator,
the Simulator will automatically open the current source file without using
the file command.  In order for the debugger to find the file, one of the
following must occur:
 
        o  The *.c files are in the same directory as the COFF output file
        o  The paths of the *.c files are included in the D_SRC environment
           variable.
        o  The paths of the *.c files are included on the command line with
           the -i option.
        o  The use command can be used to specify the path of the *.c files
           (only one directory at a time).
 
If the file command is used to open a text file, the entire path is always
needed unless the file is in the current directory.
 
The same problem exists in the C4x and C5x C Source Debugger User's Guides.
 

Bug Description

BUG DESCRIPTION
===============
When the FSXOUT bit (SPORT Global Control Register bit 2) is configured
for the FSX to be an input pin (FSXOUT=0), the SPORT does not work properly.

Bug Description

BUG DESCRIPTION
===============
C3x  simulator does not handle register conflicts in the pipeline after
a parallel store instruction properly.  The simulator takes the old
value of the conflicting register.
 
An example section of asm is given below:
 
    STI      R1,*+FP(2)
    ANDN     R1,R0,R2
    STI1     R2,*+FP(1) ||  STI2R2,*AR0
 
    LDI      @CONST+2,AR1
    LDI      *AR1,R0           ; Sim used old value of AR1 here
 
 
The simulator blows up on the last access - the one that
implements the circular buffer - if the BK register contains 0.
 

Bug Description

Getting multipule errors when using the windows version of the
C3x Simulator:
 
;Loading file.out
; 473 Symbols loaded
; --- Memory access outside valid range: 00880000
;Check memory map
;Name "main" not found
;Undeclared port address
;Undeclared port address
;Name "check_for_message" not found
 
The DOS version, which uses the same siminit.cmd works Fine.
 

Bug Description

BUG DESCRIPTION
===============
The Simulator incorrectly handles the following code segment.  When single-
stepping through the program, it seems to do the first store correctly, but
when the next instruction (lb1 r0, r1) is executed, the memory location to
where the store occurred is reset to 0h.
 
_c_init00       ldp data_addr
                ldi 02244h, r0
                ldi @data_addr, ar1
                lb0 r0, r1
                sti r1, *ar1++
                ;nop
                lb1 r0, r1
                sti r1, *ar1++
                br _c_init00
 
 
If a nop is placed after the first sti instruction, the first sti
works correctly.  The second sti always works correctly.
 
This bug only occurs if the code is being executed from internal memory.
It does not seem to matter if the store is made to internal or external
memory.
 

Bug Description

BUG DESCRIPTION
===============
The ma command does not seem to work with the "writeonly" type parameter.
 
ma 0x83000000,1,writeonly
fill 0x83000000,1,10
wa *0x83000000
 
The intent of "writeonly" was to allow the Debugger to read and
write that memory, but to fail if an instruction attempted to write to that
memory location.

Bug Description

BUG DESCRIPTION
===============
The ROMEN pseudoregister is not documented.

Bug Description

BUG DESCRIPTION
===============
The RSQRF and the RCPF instructions do not work properly.  The vales
returned are not correct.  In fact, they both return 32-bit results instead
of 16 bit results.
 
RSQRF   4ccccc00h instead of 4d000000h
RCPF    23d70800h instead of 24000000h
 

Bug Description

BUG DESCRIPTION
===============
The simulator does not work correctly for the insstruction after the
SET COND bit in the Status register is set.
 
This program does not work properly.  It should branch to START and not
reach END since the SET COND bit is set in the ST register.
 
        .global START
START
        LDI 0, BK
        OR 8000h, ST
        LSH -12,BK,IR0
        BZD START
        NOP
        NOP
        NOP
END     B       END
 
This program works since it seems that the problem is that the new SET COND
is not realized in the instruction following the instruction that sets the
bit:
 
        .global START
START
        LDI 0, BK
        NOP
        OR 8000h, ST
        LSH -12,BK,IR0
        BZD START
        NOP
        NOP
        NOP
END     B       END
 

Bug Description

BUG DESCRIPTION
===============
The TOIEEE instruction does not work properly with the following floating
point values: 0, -0.5, -1.0, -0.625, -0.03125.  The answers should be
00000000h, be000000h, be800000h, bc800000h, bc000000h, respectively.

Bug Description

BUG DESCRIPTION
===============
The simulator fails to properly execute DMA autoinitialization when:
  1. the first transfer in an autoinit sequence is complete
  2. the control word pointed to by the link pointer
     has transfer mode set to 11 (DMA stops after transfer
     is complete and does not perform next autoinit until
     CPU restarts by writing ones into START bits of DMA
     control register).
 
If the DMA is operating in split mode with only the primary
channel output FIFO connected to a file, the auxiliary channel
does not autoinitalize and the primary channel does not proceed.
 
With DMA operating in split mode, and both channels autoinitializing
the primary channel goes ahead of auxiliary channel. Is should be
a one-one situation.
 
The primary comm port does not continue after the auxilary comm
port has stopped.

Bug Description

BUG DESCRIPTION
===============
The C4x SPARC and PC Simulators do not handle the DMA rotateing priority
correctly.  When the PRIORITY MODE bit is set to 0 in the DMA channel 0
Control Register, the Simulator uses the fixed priotity mode.

Bug Description

The sconfig (Load Screen Configuration) command on the Windows V1.30
Simulator causes a GP fault.