TRANSLATION ASSISTANT 1.00,1.10,1.10b,1.30

ANSI COMPILER 1.00,1.10,1.10b,1.30

The v1.0 xref27 utility occasionally generates an illegal
operation error on Windows 95 and a Dr. Watson error on
Windows NT.

An instance has been found where, for a short C program, the
compiler won't allow both float.h and math.h to be included
in the file simultaneously. If math.h is included, float.h
produces an error. Without math.h, float.h is included as normal.
 
The error produced is "cannot open include file "

The 1.00 c 27x compiler can generate incorrect constants. For
example, the two C instructions
           int  a= 9999*32768 /10000;
           int  b= 9999*32767 /10000;
 
will generate the following constants:
         a = 0x7ffc   (expected)
         b = 0x2      (incorrect --- 0x7ffb is expected)
 

problem:-o option of the compiler causes stack corruption.
When a file is compiled with command line compiler options
"-skg -al". The code runs fine. But when the code is compiled with
the -o option: "-skgo -al", a run time stack corruption occurs and
a variable is stored incorrectly even though it
was calulated correctly in the ACC.

Given the mod operation 'num % den'  and:
1. num is either an int, unsigned int, or long  variable
2. den is an immediate value that is exactly 65536
3. optimization is not used
 
The compiler will emit the shift instruction 'SFR ACC,0' which is
not a legal ankoor instruction.
 
Workaround
----------
The workaround is that when num is int or unsigned int the mod
operation will just return num anyway, so remove the mod operation.
 
Where num is long the workaround would be to change num to
unsigned long or use the optimizer.
 
 
 

The compiler may incorrectly calculate offsets for array MSB accesses.
 
 

The C-Compiler is working correctly, it is not interlisting the
C and assembly code for some functions.
 
The compiler usually interlists assembly and C code for each line
of C except when a C label is present when it interlists a block
of C code with its assembly code.
 
 

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().
 
NOTE: This is same as bug # SDSsq04151.
 
 
 

The compiler fails with the following error if a 2-dimensional
array of far type is declared :
 
INTERNAL ERROR: no match for PLUS

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()
 

When trying to compile a file using the -pm option, the compiler
tried to invoke "ilink" and could not find it. There doesn't seem
to be such an application with this version (V1.10a) of the
codegen tools.
 
The exact command line is:
 
cl27 -pm -o3 -op1 
 

High byte of word is zeroed out when making low byte of word assignments.
This only happens when using an assignment from another structure. Immediate
values work correctly.
 
Workaround
----------
Reversing order of assignments works properly when using another
structure to make assignments.

When building a .c file, errors are reported in the DOS shell
window (standard error), but not in the .err file as
expected.
 
The -pdf option is a PARSER option used to redirect parse errors
to a file.  The problem in this case is that there is a bug in
the code generator which causes it to output incorrect assembly.
The errors being generated are assembler errors and not parser
errors, hence no output to the .err file.

BUG DESCRIPTION
===============
A write followed with a Read to the same memory address on the XINTF will
get old data due to the pipeline phases.  The proposed fix of having the
compiler adding a NOP between the Write Modify Read has to be extended to
Volatile structures.  If a write to a peripheral register causes changes to
other registers in the structure, we will read old data.
 

BUG DESCRIPTION
===============
The following piece of code gives a "Value of expression has
changed due to jump expansion" error in version 1.30b.
====================================================
Y       .set    2
        .if     Y == 1
X       .set    20
        .elseif Y == 2
X       .set    25
        .endif
 
NOTHING   .macro        ZN
        .eval   X+ZN,Z
        RPT     #Z
        || NOP
        .endm
 
        .asg    0,ZONE
        .loop   10
        NOTHING ZONE
        .eval   ZONE+1,ZONE
        .endloop
==============================================

BUG DESCRIPTION
===============
 
The compiler generates an error "INTERNAL ERROR: no match for ASG"
when compiling code using far data pointers.
 
The compiler is not handling the case of:
         func((int far *)(long_constant + var)).
 
The workaround is to cast the constant to an (int far *) before
involving it in an expression:
        func((int far *)(long_constant) + var);
 
 
 
 

BUG DESCRIPTION
===============
 
The compiler is not generating an array reference of the type
arr[index], where the array elements are a structure and the
array is far.
 
Workaround:
-----------
Change the following macro found in sc_defs.h
 
from:
#define  SC_CALC_PTS_LPC(index)  { PTSList[index].flags.b.modified = TRUE;
PTSList[index].lpc = ~(PTSList[index].w0.word0 ^ PTSList[index].w1.word1 ^
PTSList[index].threshold ^ PTSList[index].length);}
 
to:
#define  SC_CALC_PTS_LPC(index)  { PTS far *temp = &PTSList[index];
temp->flags.b.modified = TRUE; temp->lpc = ~(temp->w0.word0 ^ temp->w1.word1 ^
temp->threshold ^ temp->length);}
 
 

BUG DESCRIPTION
===============
 
CL27.exe generates internal error "INTERNAL ERROR: no match for PLUS" when
declaring arrays of 3 dimensions or greater of far type.
 
 

BUG DESCRIPTION
===============
 
ASM27.exe evaluates the following instruction:
        7FFFFFFFh - 07FFFh % 65535
equal 0.
 
The correct value shuold 've been 7FFF8000h.
 
Workaround:
-----------
If you mask off the lower 16 bits first then you can achieve the
results 8000h for the following problem.
Example:
        mov     @address, #((Dummy & 0FFFFh) % 65536)
 
will produce the correct opcode.
 
IMPORTANT:  This workaround does not work for all cases.
Only if the mod value (65536) is a power of two will this work.

The compiler may generate the following error message when
optimization is used:
 
"code.c", line 6: INTERNAL ERROR: >>>register allocation failed:
 
 
Workaround:
===========
Remodel the first expression by declaring Multiply1 as a long.

BUG DESCRIPTION
===============
The compiler fails to generate .obj file when -pm compiler
option is used.
The ilinker fails to rename its output to the input name.
There are no known workarounds for this problem.
 

When compiling the following in C:
int a,b,c;
a = ((long)b * (long)c) >> 15;
 
The compiler produces the following:
 
        SETC      SXM
        MOV       T,*-SP[4]             ; |17|
        MPY       ACC,T,*-SP[3]         ; |17|
        MOVH      *-SP[5],ACC,1         ;
 
"MOVH  *-SP[5],ACC,1" is not a valid syntax.  It should be "MOVH *-SP[5],ACC <<
1".  The code compiles and runs correctly with both syntaxes, however, the
first one is undocumented and may confuse users.
 

The parser, when handling the cast of an immediate value to a far pointer
treats the value as an int, when it should be treated as a long.  This
only affects the handling of immediate values, variables cast to far
pointers are handled correctly.
 
Example code:
#define MEM_START       0x3F0040L
int TestIt()
{
    far int * Ptr = (far int *)MEM_START;
    *Ptr = 0;
    return *Ptr;
}
 
Workaround 1
------------
#define MEM_START 0x3F0040L;
int TestIt()
{
    long temp = MEM_START;
    far int * Ptr = (int far *)temp;
    *Ptr = 0;
    return *Ptr;
}
 
When the optimizer is used, there is no code penalty for allocating
local temp.  There is overhead if the optimizer is not used.
 
Workaround 2
------------
Use the linker and not the C program to define hard addresses.
 
extern far int MEM_START;
int TestIt()
{
    far int * Ptr = &MEM_START;
    *Ptr = 0;
    return *Ptr;
}
 
Use the linker command file to define the hard address:
_MEM_START = 0x3f0040;
 
This is probably a better coding practice since it makes the
C program more portable and moves the assigning of addresses
to the linker.

ASSEMBLER 1.00,1.10,1.10b,1.30

BUG DESCRIPTION
===============
 
Need to output filename when reporting errors
 
 

Linker address checking may generate an error such as
"16-bit relocation out of range" if what appears to be
a 16 bit negative value is used.
 
For example:
                         .def    start
MY_TABLE                 .usect  "DATA_SECT",60
MY_TABLE                 .equ  (MY_TABLE-1)
                         .text
start:                   nop
                         .word MY_TABLE
 
will generate an error.
 
A workaround is to change ".word MY_TABLE" to ".long MY_TABLE"
 

Instructions of the form:
 
   mov  *xar7, #label
 
are not allowed by the assembler but are valid instructions.
 
 
Not a bug

Absolute Listings are not always generated for all files.
The incorrect Listing files do not contain the absolute addresses.

The PC assembler crashes with an Invalid Page Fault error if
the source code has errant code like :
 
     movb    AH.#40
 
instead of
 
     movb    AH,#40

The assembler with the -a option is getting confused when it
automatically changes 2 word instructions to 1 word instructions (in this case,
a B to a SB).  So the abolute listing can't resolve the absolute address.  In
the following code,
 
start:
        b               loop1,neq
loop1
 
if you try to run the absolute lister, the error is displayed:
"loop defined differently in each pass"
 
 

The assembler does not recognize symbols that are used as
indirect operands. For example, if symbols are equated to
constant values like :
 
     AA      .equ               0
     MM      .set               4
 
and you have the following instructions in the code:
 
mov     AL, *+XAR6[MM]
mov     T, *+XAR6[AA]
 
The assembler fails with the error :
 
*** ERROR!  E0003: Error parsing indirect operand

Unable to generate an absolute listing using ASM27 ALPHA Ver 1.10.

The following instructions are invalid:
 
 MOV  XAR7, AL
 MOV  XAR7, ACC
 
However, the assembler does not flag either of these
instructions with an error message when assembled.

BUG DESCRIPTION
===============
PUSH ACC & POP ACC are not supported; however, if typed, they
assemble, with bad repercussions.
 

This is due to a bug in the assembler while processing the
.global directive and has been fixed.
 
The absolute lister gives a "defined differently in each pass"
error.

The assembler may generates a warning for a possible AR/BANZ
pipeline conflict that does not exist.
 
"code.asm", WARNING! at line 12: [W9999] Possible AR/BANZ pipeline conflict
 
This is a warning and can be ignored if there is not an actual
conflict.

asm27 1.30a generates an incorrect constant value
Assemble the following and observe the results in the .lst file:
 
CONST1     .equ 6901
CONST2     .equ -(65536*2048)/CONST1
CONST3     .equ  (65536*2048)/CONST1
 
CONST2 and CONST3 will be B408 and 4BF8, resp. But if the same
is assembled with 1.10a the results will correctly be B407 and
4BF9, resp.

LINKER 1.00,1.10,1.10b,1.30

HEX CONVERTER 1.00,1.10,1.10b,1.30

The hex27 utility will give the error:
 
   >> error reading COFF file
 
If the *.cmd file used contains comments in certain places.
 
On the line that reads the out file the comments line
exceeds the buffer.
SC.OUT                  /* Input COFF file name.                        */
 
This is a bug and will be fixed in next release.
 
The Workaround:
To cut some spaces out of the line above
For example:
SC.OUT                  /* Input COFF file name. */
Will work

DOCUMENTATION 1.00,1.10,1.10b,1.30

The predefined macro _TMS320C27xx stated in Pg. 2-19 of the
TMS320C27xx Optimizing C Compiler User's Guide ( SPRU212A) is
incorrect. It should actually be _TMS320C27XX.

The C27xx Assembly Language Tools User's Guide does not give
a description of the hex27 -byte and -order command line
options.

The INPORT, OUTPORT, and IOPORT memory types are not documented
in the C27xx C Source Debugger Manual SPRU214B but are
implemented in the tools.
 
These should be included in the table on p4-13.

In SPRU214B TMS320C27xx C Source Debugger User's Guide Page 2-6
states:
 
"You must reset the emulator before invoking the debugger."
 
The word "must" in this sentence has caused some confusion in
the field.  Emurst does not need to be run every time you
bring up the emulator.  Only when you first do, loose power,
reboot etc.

BUG DESCRIPTION
===============
 
Although 'LC' is a valid C27xx instruction, no information is
provided in the instruction set manual.

BUG DESCRIPTION
===============
 
The instruction LRET (long return) is not documented in
TMS320C27xx CPU and Instruction Set Reference Guide
(SPRU220B)

BUG DESCRIPTION
===============
 
IOPORT instruction is not in the documentation.

BUG DESCRIPTION
===============
Document the following in the users guide.
the following syntaxes are legal and should not be
        changed:
 
                actual mode             short hand
                -----------             ------------
                *-SP[0]         ==      *SP
                *+AR0[0]        ==      *AR0
                *+AR1[0]        ==      *AR1
                .
                .
                *+XAR7[0]       ==      *XAR7
 
        They are a short hand notation that is commonly used.
 
 

SIMULATOR 1.00,1.10,1.10b,1.30

The simulator incorrectly disassembles the AND  IER,#16BitMask
and OR  IER,#16BitMask instructions. Only the disassembly
display is incorrect, the instruction is in fact simulated
correctly.

If a line has more than apx 95 characters the simulator, version 1.10,
will not execute properly.
It returns the following message stating that an "illegal
operation has been performed".
 
Immediate workaround is to split the command line up into different
segments.

BUG DESCRIPTION
===============
 
See Problem Enclosure
 
 

The mem command does not work correctly for v1.20 of the C27xx
simulator. When you try to change the addresses displayed in
the memory window, the simulator may create a new memory window
rather than adjust the addresses.
 
example: mem 0x100
         mem 0x200
 
may create two memory windows rather than one.

The v1.00/v1.10/1.20 simulator was not built with C I/O,
although it says it was when you do the version+ command.

The disassembly window shows relative branch instructions with
the offset value rather than resolving that value to a symbol.
 
This is illustrated by the following code.
 
        .def    start
        .bss    x, 4
        .bss    a, 4
        .bss    y, 1
        .data
table:  .word   1, 2, 3, 4
        .word   8, 6, 4, 2, 0
        .text
        .def    _main
_main:
start:  MOVL    XAR6, #table
        MOV     AR2, #x
        MOV     AR3, #8
loop:   MOV     AL, *XAR6++
        MOV     *AR2++, AL
        BANZ    loop, AR3--
sop:    SPM     0
        MOV     AR2, #x
        MOV     AR3, #a
        MOVW    DP, #y
        MOVP    T, *AR2++
        MPYS    P, T, *AR3++
        MOV     T, *AR2++
        MPYA    P, T, *AR3++
        MOV     T, *AR2++
        MPYA    P, T, *AR3++
        MOV     T, *AR2
        MPYA    P, T, *AR3
        ADD     ACC, P
        MOV     @y, AL
        LRET
 
The
        BANZ   loop, AR3--
instruction is displayed as:
        BANZ   0xfffe, AR3--

If you create a memory window (ex: 'mem 0x60,x,test') the window
opens with a large blank space between the address field at
the top and the displayed memory.
 
Ifyou resize the window, the extra space disappears.

When displaying code assembled with -g option, and the
code ends with a branch, the source file window does not
allow you to step to last line of code
(branch instruction).

In the simulator, if you open a second memory window and save the
screen configuration, the screen configuration does not get
reloaded correctly if the simulator is closed and restarted.
The second memory window is not in its saved location.
 
 

Under the File menu you can open a command log file as
expected. But, when you're finished and want to close the
file, the File/Close options are greyed out and do not
allow you to close the log file.
 
As a work around, use "DLOG CLOSE" at the command prompt to
stop the log file entry process.
 

You can not view a long with wa command with indirection, like
(wa *long_var,var_label,x). You will only get lower 16 bits.
 

The simulator could give an "access outside valid range" when
no such access occurs.
 
 

BUG DESCRIPTION
===============
 
Simulator hangs if you try to step thru an IDLE instruction.

Simulator does not update the memory window correctly.
 

Disassembler allows disassembly of invalid instructions and
executes invalid instructions.
  MOV  XAR7, AL
  MOV  XAR7, ACC are not  valid instructions.

DEBUGGER 1.00,1.10,1.10b,1.30

Coff information that is provided does not provide enough information about the label to let the debugger know
that the code was loaded in data and that it is being run in the program.

The file command should reload the source file if it has been
changed.  It currently does not update the source window
unless the window is closed before the file command is given.

The v1.20 simulator and v1.00 XDS512 emulator does not always
display all labels from assembly source code.  Only the last
label is displayed in certain cases.
 
Breakpoints can still be set to the labels, they just do not
show up in the disassembly window.

The v1.20 simulator and emulator loses track of window sizing
in certain cases.  When the file window is closed and the code
is loaded again, the window will reappear as a different size.

In the c27x debugger, under Configure->Breakpoints, you can
specify symbolic addresses to set breakpoints at.
You can also save and load lists of breakpoints when necessary.
 
When you save the breakpoints, only the associated addresses are
saved, and not the labels.
 
The save option should save the labels, not the addresses of the
labels.
 

Reloading the same filename using LOAD command makes the watch
window disappear.

When invoking successive watch windows(after they are closed with
new load command), the window location moves down and to the
right a little everytime. After doing this several times, the
watch window opens out of view of the window.

On the c27x Debugger, the patch assembly generates a GPF in Windows 95 when
you:
 
a) Right click on an instruction and invoke patch assembly
b) Try to move the cursor within the line by clicking on it with your mouse.
 
If you don't click on the line with your mouse and just backspace to the
appropriate spot, everything seems to work fine.  But after the line is
highlighted for patch assebmbly, any attempt to move the cursor with the mouse
will cause the debugger to crash hard.

The debugger does not allow you to change the values in a watch
window when using realtime mode.
 
This gives an error similar to:
 
Unable to edit while the target is running.
Halt the target before changing values.
 
This should be allowed in the debugger.
 
A workaround to this is to use a command similar to:
 
e *value = 0x2000
 
at the command line.

Any label longer than the width of the label field in the
disassembly window gets chopped off by the instruction on
that line:
C27x Tool:  Debugger
SW Version: v1.00b
 
Description:
 
Labels in disassembly window get chopped off if too long.
 
Analysis:
 
Any label longer than the width of the label field in the disassembly window
gets chopped off by the instruction on that line.  On the c2xx debugger, you
could always see the full label, and the instruction was moved over
accordingly.

The move command does not function properly on the Emulator or
the Simulator.

The move command may cause the simulator/emulator to crash with
an invalid page fault error.

When you press the ESC key while running a take file, it does
not always halt execution of the file.
 
For example, if ESC is pressed during a load command, the take
file will halt execution with the message - Aborted by user.
 
If ESC is pressed during a run command, the next command in the
take file is executed.

When stepping through the code using Debugger version 1.00 there
is inconsistency between address shown in disassembly and the PC
register. For example:
The Program Counter (PC) register contains 0x2E0000, but the
instruction pointer in the Disassembly window points to 0x2DFFFF.

When the debugger is open with a .out file loaded, you cannot
write over that .out file with a file of the same name.  If you
try to move a file of the same name from another directory
over this file, you get a Windows error stating that the file
cannot be overwritten. However, copying and pasting the file
works.

In some instances a dialog box with the following title:  "Resolve
Ambiguity" is produced, when code is executed on the debugger.
This happens only when the code is compiled without any optimization.
The dialog box does not appear when code is compiled with optimization.

The v1.00b emulator does not save the location and size of
additional memory windows (ssave, CTRL-S).
 
If you create a memory window, place it in a certain area,
size it, save the screen config, and quit the emulator.
 
When you restart the emulator and reopen the memory window, it
will not open in the correct location or with the correct size.

Tthe variable window in the C27x debugger (emulator v1.00b
running on win95) does not display variables according to display
formats entered by the user via the SETF command.

The dissassembly window shows the incorrect value for the
immediate operand.
 
For example: Dissassembly window shows MOV XR6, #0x28 the
correct value is 0x20008 which is loaded correctly in the XR6
register.
 
The three zeros in the middle appear to me missing.

Patch Assembler allows
           MOV   XAR7, AL
     to be entered as a valid instruction.
     The patch assembler should flag this as an illegal opcode.
The silicon identifies this as a bad opcode by
trapping it but the patch assembler accepts it as good
instruction.

BUG DESCRIPTION
===============
 
Debugger/Simulator does not display structures correctly.
When loading some code in the c27xx simulator or debugger, the
structure called 'array', when pulled up in a watch window,
displays the wrong values.  The values can only be seen in the
memory window correctly.  The code functions correctly.
 
This seems to be only a display problem.
 
Workaround:
Look at structures in the memory window, don't use watch windows.

EMULATOR 1.00,1.10,1.10b,1.30

The v1.00b XDS-510PP emulator does not work.
 
This is due to a name change of the JTAG scan manager DLL from
smg510w.dll to smg51095.dll.

When cstepping C code using the emulator, 'out of range' errors
could appear in some instances. This might happen when the asm
instructions that makeup the C statement end in a branch with a
negative offset. It appears that the emulator is calculating
where to set the breakpoints for the CSTEP based on the offset
as if it were not a signed number.

Request to be able to disable call and variable windows.
 
When trying to implement multiple stacks using the stack
pointer in the C27x, the debugger gets confused when trying to
resolve the function calls in the call window (in C).  The
error "Corrupt call stack" comes up because the SP has been
changed by the user.
 
We need to be able to turn off the Call window (and possibly
the Variable window) so the c27x does not try to look for
things on the stack that are not there.

BUG DESCRIPTION
===============
If you block out a range of addresses, and there is a
"runaway" RPT instruction, those addresses are still
affected.
 
For example, the emulation addresses (0x800)
and peripheral addresses (0xA00) could be affected by a
runaway RPT instruction at block B0. (0x400-0x7ff)
 

BUG DESCRIPTION
===============
 
Set a breakpoint on a label on a separate line from an instruction in the
asm source file, and the BP could be set to the previous instruction.
 
                ret    ; click on lable_1 to set BP and the breakpoint will
be set on this instruction.
 
lable_1:
 
                MOV AL,#2

BUG DESCRIPTION
===============
 
Can not write the control register to trigger some event.  Some registers
are the same address for write and read, but do diferent functions.  Prime
example is the Receive / Transmit register on the 320c203 UART.  They are 2
different registers gated by RD or WE.  Their location can be written
everytime by ?*0=0x1234.  This is the present workaround.

BUG DESCRIPTION
===============
The EPC (Emulation Pin Control) dialog box may not program
the EMU pins correctly for several option settings.
 
For example, selecting "Setup EMU0: Force low" does not
force EMU0 low. Likewise, selecting "Setup EMU0: Force high"
does not force EMU0 high. Selecting "Setup EMU0: Drive
low when device halts" won't cause it EMU0 to be driven low
when the device halts.

TRANSLATOR 1.00,1.10,1.10b,1.30

The v1.0 Translator Assistant will occasionally give an illegal
operation error and die when using the -w and -l switches.
 
The workaround is to not use the -l switch.

When the translator encounters a macro that has not been defined,
it produces an error, but then prevents the rest of the code
from being translated. The translator should instead proceed
with translating the remaining code in addition to generating the
translation error.

BUG DESCRIPTION
===============
 
Translation of :  SPLK #(Value*35)/100, REG
 
results in:       MOV  @REG, #(Value*35)/100
 
which does not assemble.
 
The temporary fix is to further bracket the immediate value
((Value*35)/100), but the translator should do this.
 
Translation of:   SPLK  #(Value<<8 + New),*+
 
results in:       MOV  *++, #(Value<<8 + new)
 
which does not assemble. The temporary fix is to further
bracket the immediate value  ((Value<<8) + new) .
 

POST LINK OPTIMIZER 1.00,1.10,1.10b,1.30

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

Commented code beginning with ";//" are misread as directives
or instructions by plink, and errors result.
 
Workaround:
If you have a lot of code with these kinds of commented lines,
write a simple program or script that changes the single semi-
colon to a double semi-colon (i.e. ";;//")

The post link optimizer sometimes incorrectly removes DP instructions.
 
If users see DP's that are incorrectly removed from a function,
they can work-around it by making that function a .global.

TRANSLATION ASSISTANT 1.00,1.10,1.10b,1.30