Bug Description

ppcg and mpcg abnormally terminate when presented with a switch case constant
which is unsigned and has the high bit set.
 
Example:
 
void test(unsigned int b)
{
   switch(b) {
     case 0x81000001:
     break;
     case 0x41000001:
     break;
   }
}

Bug Description

   The compiler errs in generating code for interrupt service
routines declared using the "interrupt" keyword, by generating
code in the first instruciton of the routine that overwrites
the value of d0, without first saving its current contents.

Bug Description

   The compiler errs in generating an reti1 instruction in parallel
with an instruction which modifies the stack on return from an
interrupt service routine generated using the "interrupt" keyword
in C source. Since the reti1 mnemonic is representative of the
instruction "sr = *sp++" so this renders the instruction sequence
shown below as :  sr = *sp++ || d0 = &*(sp ++=4) . This sequence
will cause the stack to be corrupted, since the incerement is not
performed before sr gets popped off the stack.
 
   i.e. code sequence generated by compiler at return from interrupt
 
             reti1
    ||         d0 = &*(sp ++= 4)
             reti2
             reti3
             reti4

Bug Description

When using mpcl from the command line with a large number of defines, mpcl
fails and reports "abnormal termination of mpac."
 
Example:
mpcl -g  -ft /tmp -dAZZZZZZZZZZZZZZZ -dBZZZZZZZZZZZZZZZZZZZ \
 -dCZZZZZZZZZZZZZZ -dDZZZZZZZZZZZ -dEZZZZZZZZZZZZZZZZZZ \
 -dFZZZZZZZZZZZZZZZZZZZZ -dGZZZZZZZZZZZZZZZZZZZZ \
 -dHZZZZZZZZZZZZZZZZZZZZZZ -dIZZZZZZZZZZZZZZZZZZZ \
 -dJZZZZZZZZZZZZZZZZZZZZZZZ -dKZZZZZZZZZZZZZZZZZZZZ \
 -dLZZZZZZZZZZZZZZZZZZZ -dMZZZZZZZZZZZZZZZZZZZZ \
 -dNZZZZZZZZZZZZZZZZZZZZZZZZ -dOZZZZZZZZZZZZZZZZZZZZZZZZZZ \
 -dPZZZZZZZZZZZZZZZZ -dQZZZZZZZZZZZZZZZ  -dRZZZZZZZZZZZZZZZZZZZ \
 -dSZZZZZZZZZZZZZZ -dTZZZZZZZZZZZ -dUZZZZZZZZZZZZZZZZZZ \
 -dVZZZZZZZZZZZZZZZZZZZZ -dWZZZZZZZZZZZZZZZZZZZZ  -dXZZZZZZZZZZZZZZZZZZZZZZ \
 -c test2.c -z link.cmd -o test.out

Bug Description

When declaring several large initialized arrays, the compiler will sometimes
generate an error:
 
   The following symbols are undefined:
     VRxx
 
Large arrays may cause instruction to be generated
which use "virtual registers" which are internal to
the compiler.

Bug Description

Input line buffer for DOS was 2K, because of 640K memory limit.
ANSI requires only 512 bytes, but the documentation states a limit of
16K.

Bug Description

ppcg and mpcg abnormally terminate when presented with a
switch case constant which is unsigned and has the high bit set,
 
Example:
 
void bad(unsigned int b)
{
   switch(b) {
     case 0x81000001: /* Causes abnormal termination: high bit set */
     break;
   }
}
 
void good(unsigned int b)
{
   switch(b) {
     case 0x41000001: /* Doesn't terminate: high bit not set. */
     break;
   }
}

Bug Description

There is a general problem when data is at a location in
static data that is greater that 32767 bytes away for 32 bit
or 16 bit data items and 65535 bytes away for 8 bit items.
The symptoms of this problem are the message
 
   E0004: Address offset is too big
 
from ppasm in response to the C compiler generating bad code or
 
   COMPILER ERROR: no match for VARADDR
 
from ppcg.
 
An example of a C program that will cause bad code to be
generated is
 
  int ar1[35000];
  int ar2[35000];
 
  void f1()
  {
 
     extern int *v1;
     extern int *v2;
 
     v1 = &ar1[0];
 
     v2 = &ar2[0];
 
  }
 
An example of a C program that will cause a compiler
internal error is
 
  int ar1[45000];
 
  void f1()
  {
     extern int *v1;
 
     v1 = &ar1[32768];
 
  }
 

Bug Description

Initialization of a string field whose length is greater than 1 and
is followed by another field which is initialized as well, may
have incorrect assembly code generated.  For example
 
struct problem
{
    char cStr[6];
    char cVal;
};
 
struct problem init_me =
{
   "a",
   '5'
};

Bug Description

The cast of a function call to an integral type, when the
function is defined to return a pointer, results in the
using the return location for an integral value rather
a pointer value.  For example
 
  char *func_return_pointer();
 
  main()
  {
    int_return;
 
    int_return = (int)func_return_pointer();
  }
 
  char *func_return_pointer()
  {
    return (char*)0x10000000;
  }
 
results in an undefined value being assigned to int_return
and the actual function return value being ignored.

Bug Description

The MP memcpy library function assumes word alignment of
source and destination parameters, without verification,
when the copy length is an integer constant which is a
multiple of four bytes in size.
 
The problem occurs whenever the address of an array or structure
is used as a parameter.  The problem occurs even if an offset
or a cast is used.
 
i.e. When memcpy is used with a non-word boundary, memcpy misaligns the
destination data.

Bug Description

The C compiler optimizer aborts.

Bug Description

When the -x switch is used, the compiler may sometimes use a store (st)
where it should use a direct store (dst).

Bug Description

See table on CG:5-27.
 
Both minit() and ltoa() are defined, and listed in the CodeGen manual,
but neither is declared in stdlib.h, as they should be.

Bug Description

The PP C compiler will produce incorrect assembly output on the following
C code segment when optimization is used:
 
C code segment:
   if ( out < 0 )
      out = 0;
   else if ( out > 0xFFF )
      out = 0xFFF;

Bug Description

Bug Description

Double constants are generated into assembly statements of the form
 
   .long   word1,word2
 
Since the load and store double word command read words followed by word1
a double value is loaded in the reverse order that is required.
 
The initialization should be
 
   .long   word2,word1

Bug Description

The bitwise XOR generates incorrect code when the optimizer is
invoked (mpcl).  In the code:
 
if ((y0 & 0x3f) ^ 0x20)
   y0++;
 
The generated code checks only bit 5 of (y0 & 0x3f) to see if
it is set.  If it is set, it gives a false value and if not set,
it gives a true value. It should give a true value for all
values except for 0x20 ( which is 32) .  An example of an incorrect
case is 33.  Bit 5 is set so it thinks it is the same as 0x20
but it isn't.
 
This will only occur when the second operand has only one bit
set.  If there are more than one bit set, it works correctly.
 
This occurs on the v1.10, v1.13, and v2.00 of the tools when
the optimizer is invoked (-o0, -o1, -o2 or -o3).
 
A simple workaround is to do a NOT EQUAL instead of a XOR.
 
if ((y0 & 0x3f) != 32)
   y0++;
 
This will work correctly.
 
 
 

Bug Description

The bug is generated by the single increment optimization
when it does not realize that the required offset
would be too large.  The single increment optimization
should make no chnages in such a case.

Bug Description

The compiler generates the error:
 
[code.c]
>> "code.c", line 11: COMPILER ERROR: no match for PLUSASG
 
when compiling the following code using -o0:
 
typedef struct
{
   int    t;
} strucA;
 
static void test(strucA *args)
{
   int *t1;
   strucA *a = args;
 
   a++;
   t1 = &a->t;
}

Bug Description

When the following code is compiled using -o1, -o2, or -o3:
 
double asmBug (double x)
{
   double a = (float) -0.5;
 
   return a * (x * x) - 4 * a;
}
 
The following error is generated:
 
         fadd.sdd  --2.0000000000e+00,r2,r2
"code.asm", line 17:  A COMPONENT OF THE EXPRESSION IS INVALID
 
From the assembly code generated:
 
        fmpy.ddd  r2,r2,r2
        fmpy.sdd  -5.0000000000e-01,r2,r2
        fadd.sdd  --2.0000000000e+00,r2,r2
 
it appears the optimizer has turned the return expression into
 
        return x*x*(-0.5)--2.0
 
which has apparently converted the "- 4 * a" to "--2.0".

Bug Description

When using optimization level 2, the optimizer may generate code
that does not increment a value used in the loop.  For example:
 
   for (i=0; i < 10; i++)
   {
      arraya[i + int1] |= 0xFF;
      arraya[i + int2] |= 0xFF;
   }
 
The inner loop of the generated code looks like:
         addu      -1,r4,r4
         addu      -1,r6,r6
L4:
;**     -----------------------g5:
;** 22  -----------------------    *(++U$25) |= 0xff;
;** 23  -----------------------    *(++U$28) |= 0xff;
;** 20  -----------------------    if ( --L$2 ) goto g5;
         move      -1,r12
         addu      -1,r8,r8
         move      -1,r11
         st.b      0(r4),r12
         bcnd      L4,r8,ne0.w
         st.b      0(r6),r11
; branch occurs
 
Note that, even though the comment says that U$25 and U$28 need
to be incremented in the loop, the actual code generated does
not change the array indices (i.e. r4 and r6 remain constant
throughout the loop.  In view of the pre-decrement of the
indices before entering the loop, the code that should have
been generated for the 'st's is:
 
         st.b      1(r4:m),r12
         bcnd      L4,r8,ne0.w
         st.b      1(r6:m),r11

Bug Description

The illegal use of register R1 as the destination in a floating-point write
does not generate an error message.
 
Example:
 
_main:
         move      040000000h,r3
         move      03f800000h,r2
         fadd.sss  r2,r3,r1
         jsr       r31(r0),r0
 
The floating-point add instruction above should generate an error message,
but does not.

Bug Description

The assembler does not allow aMPY||SADD instruction in revision less than
3 silicon.
 
The instruction forms onpage 8-88 such as:
 
        d3 = d1*d2
        || d4 = d6 + d5>>-d0
 
return an "Illegal combination of 6 operand operation" error.  Use the -v3
option to assemble correctly.
   

Bug Description

   In PP assembler if a multiplication and an addition are
done in parallel, the multiplication instruction must be
specified first or the assembler generates an error.
 
  i.e.   d1=d2*d3 || d4 = d5 + d6      <=== works okay
 
         d4 = d5 + d6 || d1=d2*d3      <=== doesnt work

Bug Description

EALU||ROTATE instruction assembles incorrectly.
 
Example:
  d0 = FOO
  d1 = ealu(FOO: d1&~@mf || d5 = d1 \\ 8)
This is assembled incorrectly as: 70092080
                   But should be: 72292880

Bug Description

Ealu instructions are sometimes assembling incorrectly when
appearing without parallel instructions.
 
Example:
 
This Assembles incorrectly without parallel instructions:
temp1_temp2     .set d1
mask            .set d2
test2           .set d4
   test2 =me ealu(MULT_SHIFT:(temp1_temp2\\31&mask)|(@mf&~mask))
 
   Incorrectly assembles as: 70242100
     But should assemble as: 72242100
 
 
   The instruction assembles correctly once parallel instructions are added:
   d0 =r (d0 * d0)<<1
      || test2 =me ealu(MULT_SHIFT:(temp1_temp2\\31&mask)|(@mf&~mask))
      || d0 = d0

Bug Description

  The destination register for a parrallel ealu || multiply
  operation is always assembled as one register number greater.
 
   i.e.  d0=BUG
         d1=ealu(BUG: d1+d1) || d6=d3*d2
 
 
               is assembled as
 
 
         d1=ealu(BUG: d1+d1) || d7=d3*d2

Bug Description

Instructions like the following assemble incorrectly:
 
        d3 = ealu(BLAH: d1 | d2 & @mf)
Incorrectly Assembles as:  701B2100
              instead of:  721B2100

Bug Description

The conditional source selection operator is not
allowed in MPY||ADD instructions.    For example
 
   d1 = d2*d3 || d4 = d5 - d7 [n] d6
 
When the conditional source selection operator appears
the MPY||ADD instruction a "Processor resource allocation
conflict" message is given.

Bug Description

Legal generic MPY||EALU syntax instructions will not assemble and report
"illegal combination of six-operand instruction error."
 
Example:
        d4 =u d1*d3
            || d6 = ealu(d6,d6\\d0,%d0)

Bug Description

Parallel transfer formats do not allow labels immediately following
the equal (=) that begin with "g", "m", or "h" because they are being
confused with the assignment modifiers.
 
Examples:
        d4 =h *(a10++=vvar)     ; passes
        d4 =h *(a10++=gvar)     ; fails because of =g
        d4 =h *(a10++=mvar)     ; fails because of =m
        d4 =h *(a10++=hvar)     ; fails because of =h

Bug Description

The three-operand instruction "Di = ealu(label:Dj+Dk+1)" is not
assembled.

Bug Description

The order of evaluation of expressions is specified in
the user guide in section 8.2.1, pages 8-13 and 8-14.
Expressions other than address expressions are not evalutated
in the specified order.  For example
 
  d3 = 155 - 55 + 45
 
results in
 
  d3 = 55
 
rather than the correct
 
  d3 = 145
 
Operator precedence must be strictly followed.

Bug Description

The use of index registers in an ealu is recognized but when
assembled they are not properly encoded.  An incorrect register
bank is chosen athough the correct register number is used.  For
example in
 
   d0 = MPY_TEST
 
   d1 =u d1 * d4
      || d2 = ealu (MPY_TEST: d2 + x8)
 
index register x8 is encoded as pc.  In the reported test case
 
   d0 = MPY_TEST
 
   d1 =u d1 * d4
      || d2 = ealu (MPY_TEST: d2 + x8)
      || d0 = *(a1 + [5])
 
index register x8 is encoded as its companion register d0.

Bug Description

Multiplications of the form
 
   d1 = d2*d3 << 2
 
receives the message
 
   E0004: Multiply operands must be D registers

Bug Description

Bit operations are performed without regard for operator precedence.
The result is that expressions with bitwise operations may not be
correctly evaluated.  For example
 
        d1 = 0xFFFF
 
        d2 = (d1 & 3) ^ 3
 
        d3 = (d1 ^ 3) & 3
 
The values assigned to d2 and d3 should be identical and the result in d4
below should receive the same value
 
        d4 = 3&~d1
 
the current result is that d2 receives the value 0 and d3 receives the
value of the rightmost 3 bits.

Bug Description

The instruction:
 
    d3= ealu(label: d5 -(d3 & @mf))
 
when disassembled adds a % sign and shows up as:
 
    d3= ealu(label: d5 - (d3 & %@mf))
 

Bug Description

ppasm does not support any EALU||ROTATE subfunction with a -1 in it.
See Table 4-2 on PP: 4-21.
 
Functions that do not assemble:
-1
-B-1
-C-1
-(B&C)-1
-(B|C)-1
-(B&~C)-1
-(B|~C)-1
(B&~C)|((-B-1)&C)
(B&C)|((-B-1)&~C)

Bug Description

Inserting a zero inside of an EALU function often causes the
assembler to fail.  If one of the two subfunctions is unused, it
is not necessary to insert a zero.
 
Example:
 d5 = ealu(test1: d1&((d2\\d3)&d4)) ; this will pass
 d5 = ealu(test1: d1&((d2\\d3)&d4)+0) ; this will fail

Bug Description

EALU doesn't support subfunctions (B&~C)|(~B&C) and (B&C)|(~B&~C).
 
If f1 or f2 is either of these, assembler returns error:  Unable to match
EALU explicit expression to a d0 code
 
Examples:
         d0 = ealu(test: d0&((d0\\d0)) + ((d0\\d0)&~d0)|(~(d0\\d0)&d0))
 

Bug Description

Any instruction of the forms below cause the assembler to report an
error (including ~@mf, ~(src1\\src3), etc.):
 
dst = ealu(label: src2 + ((src1\\src3)|@mf) + (src1\\src3))
dst = ealu(label: src2 + ((src1\\src3)&@mf) + (src1\\src3))

Bug Description

Assembler reports an error in instructions like the following which use
the mask generator (%src4) (including forms with ~(src1\\src3), ~%src4, etc.):
 
dst1 = src2 + ((src1\\src3)&%src4 + (src1\\src3))
dst1 = src2 + ((src1\\src3)|%src4 + (src1\\src3))
 
Note that the assembler only complains if there is no C port (%src4)
present on the left hand function f1(b,c).

Bug Description

Assembler does not support the minus 1 subfunction.  When it sometimes works,
it misassebles the function using a 15-bit immediate instead of the ALU
subfunction.
 
From PP User's Guide page PP:4-21
 
output = A & f1(B,C)+f2(B,C)
 
If f1=-1 or f2=-1, the code will not assemble correctly.
 
Examples:
         d0 = ealu(test2:d2&-1 + d3)
 
 
 

Bug Description

 
If a non-D register is used as dst2 (as x2 is used below), the assembler
will crash with a Segmentation Fault.
 
Example:
 d3 = ealu(test22: d1&((d2\\d1)) + (d2\\d1) || x2 = d2\\d1)
 

Bug Description

The retiN commands are not assembled correctly in the
beta release nor were they correctly assembled in release
1.10.

Bug Description

Directives .struct, .tag and .union do not force alignment on
32 bit boundaries.  They only force 8 bit alignment.  This means
that structures/unions containing elements requiring speific alignments
may be aligned on any boundary.  This will cause memory access failures.

Bug Description

Specification of ealuf via the "ealuf" keyword is ignored.  When ealuf is
needed, it can be generated by writing two ealu functions with the same label,
where one ealu function is the inverse of the other as in Example 2 below.
 
Example 1:
  d1 = ealuf(label1: d2+d3) ; Assembles incorrectly and ealuf is ignored.
  d1 = ealuf(d1,d2\\d3,%d0) ; Assembles incorrectly and ealuf is ignored.
 
Example 2:
  d0 = label3
  d2=d3*d4 || d1 = ealu(label3: d2+d3>>0) ; Assembles correctly as ealu
  d2=d3*d4 || d1 = ealu(label3: d2-d3>>0) ; Assembles correctly as ealuf

Bug Description

Different protection bit settings are allowed on parallel commands.
This should be reported as an error.  For example
 
  lctl =[.n] ealu(test2306: -1 || d2 =[.nvc] d1\\d7)
 
should receive an error message since "[.n]" and "[.nvc]" are not
the same.

Bug Description

The PC NT version 1.13 of ppasm incorrectly assembles the following EALU
instructions (bits 31,27 are 1 instead of 0):
 
       d2 = ealu(d5, d4\\d0, %d0)
     || a8 = d3
     || d7 = &*(-5)
Assembles as: fa1282df instead of 721282df
 
      d3 = ealu(d3, d2\\d7, %d7)
     || d1 = &*(a9 += x8)
     || d2 = &*(a0 += x0)
Assembles as: fbdb5de2 instead of 73db5de2
 
      d2 = ealu(d2, d1\\d0, %d0)
     || d3 = &*(a8 += x9)
     || *a3++ = d3
Assembles as: fa1282df instead of 721282df

Bug Description

The following ealu instruction is assembled incorrectly:
 
Assembler produces:
 
Opcode (incorrect): FA1360C4C4528C40
                                  d3 = ealu(TESTDIVIDE:
                                     d1 - (d3\\d0 & %d0) || d2 = d3\\d0 )
                                     || d4 = &*(a2 + x0)
                                     || d3 =ub *(a8 ++= [x9])
 
 
instead of:
 
Opcode (correct): 721360C4C4528C40
                                   d3 = ealu(TESTDIVIDE:
                                     d1 - (d3\\d0 & %d0) || d2 = d3\\d0 )
                                     || d4 = &*(a2 + x0)
                                     || d3 =ub *(a8 ++= [x9])

Bug Description

This bug only applies to PC PP Assmebler:
 
Performing a right shift with the shift amount in a
register causes the assembler to generate the
wrong instruction.  The mask bit in the oper field
when the F bit is set in the D0 code.
 
The assembler seems to give an incorrect opcode no matter what is done
in parallel with this right shift. A few examples follow:
 
 
  d7 = d2>>u -d3
  d1 = d2>> -d4
  d2 = d3>>-d4
       || d1 = &*(-1)
   d2 = d5>>u -d7
       || d3 = *(a10+[2])
 
The code assembles, but when it is loaded into the debugger, weird
symbols are present. The symbols are not consistent, but a common wrong
opcode looks like this:
 
 
         d7 = d2>>u SHAMROCK SHAPE  Square Root Symbol(Heart Shape)
 
         or, another common one is taking the derivative of a Heart,
 
 
The incorrect opcodes are SOMETIMES fatal (and always incorrect) causing
the debugger to hang.

Bug Description

This line of assembly code:
 
$main   d1 = d1 + d4
            || d7 = d2*d5
            || d5 = &*(88)
 
Assembles as:
 
     d1 = d1 - rmbc(d1)
     || d5 = &*(88)
 
or
 
d1=d1-(d1&d4)+cin || d5 = &*(0x58)

Bug Description

When certain syntax errors are encountered, subsequent valid instructions
are also reported as syntax errors.
 
Example:
  d0 = [,nvcz] d1 + 0x01  (syntax error is that "," should be ".")

Bug Description

Condition codes must be the same within a single instruction.  Condition
codes that differ are not given errors.  For example in
 
                d3 =[p] ealu(d2, d3=[p] d1\\d0, %d0)
                d3 =[p] ealu(d2, d3=[n] d1\\d0, %d0)
                d3 =[p] d4*d5 || d3=[z] ealu(d2, d3=[n] d1\\d0, %d0)
                d3 =[p] d4*d5 || d3=[z] ealu(d2, d1\\d0, %d0)
 
the first instruction is correct and should receive no errors.  The remaining
three instructions should receive error messages.

Bug Description

A syntax error is emitted when a two operand explicit ealu instruction
is used.  For example
 
   d4 = d4 * d4 || d3 =ealut(d2,d1)

Bug Description

Ealu in parallel with a load or store do not encode the value of
an immediate offset correctly for offsets greater than 7.  For
example in
 
        d1 =s d1 * d3
           || d1 = ealu(R: d1 + d1 >>s 1)
           || d4 = &*(a7 - 15)
 
the 15 is encoded as 7 and the 3 bit immediate form of the parallel
transfer used.  The correct encoding is to use the 15 bit immediate
form to encode the offset in the local and also the global cases.
 
Note that the disassembler does not properly disassemble the above
instruction even when the 15 bit immediate form is used.  The ealu
is not disassembled at all.

Bug Description

The following
 
   reti4 || d6 = *a1
 
is assembled as
 
   reti4 || d6 = &*a1
 
The assembly error is to assemble as a long immediate offset.

Bug Description

Long distance opeands of the B port rotator are not allowed.  For example
 
           d2 = ealu(d2,x1\\d4,d0)
           d2 = ealu(d2,d3=x1\\d4,d0)
 
receive
 
           E0004: Illegal B port specified
 
error messages.

Bug Description

The v2.00 archiver gives the following error when trying to
read the mp_rts.src, mp_cio.src, pp_rts.src, and pp_cio.src
files:
 
>mvpar t mp_rts.src
MVP Archiver                     Version 2.00
Copyright (c) 1993-1996    Texas Instruments Incorporated
  -->  error: 'mp_rts.src' not in archive format
 
A workaround is to use the sun4/unix version of the files.

Bug Description

There is a bug in the cio code involving cio writes to the host. If
the first write to a stream is larger than 256 bytes, memory in the
target and the host will be overwritten. This bug affects the function
fwrite.

Bug Description

The TCOUNT register is not accurately simulating the number of clock
cycles when external memory is being accessed.  This is also exhibited in
the runb command returning incorrect values in the clk register.

Bug Description

When PP simulators are spawned before the MP simulator, the MP simulator
may crash.
 

Bug Description

Subtraction in address offset expressions does not
always produce a correct result.
 
Example:
   d1 = d1 + 1 || d3 = a4 || *(a0 - 9) =b d4
disassembles as:
   d1 = d1 + 1 || d3 = a4 || *(a0 - 1) =b d4

Bug Description

The MP simulator contains a bug that can cause it to incorrectly execute
an MP instruction of the form "st -64(r2:m),r2."  When the simulator attempts
to execute this instruction, it incorrectly increments the value of r2 before
writing r2 to memory; the increment is supposed to follow the write.
 

Bug Description

The dst and dld commands are supposed to behave identically to st and ld
when accessing on-chip memory.  When viewing in the memory window the on-chip
location stored by dst, the value at the stored location never gets updated.
But simulation is still performed correctly.  If the location is read with
a ld or dld, the correct value is read.
 
Example:
 
        addu 0xff,r0,r13
        st   0x1010004(r0),r13
 
At this point, location 0x1010004 contains the value ff in the memory window.
 
        addu 1,r0,r13
        dst  0x1010004(r0),r13
 
Here, the memory window incorrectly still displays the old value ff.
 
        dld  0x1010004(r0),r14
 
But here you can see that the simulator actually behaves correctly
internally, because r14 contains the expected value: 1.

Bug Description

PP code submits packet transfer suspension by sending "S" bit.  However,
PP continues with ongoing packet transfer.
 

Bug Description

When the operation dX =b *(aY-Z) is combined with certain parallel
instructions, the address offset (Z) is not displayed in the disassembly
window.  An example instruction causing the problem is:
 
 *a0 = d0 || d1 =b *(a8-8)
 
which disassembles incorrectly as:
 
 *a0 = d0 || d1 =b *(a8)

Bug Description

Just prior to entering main(), when a variable has not yet become valid,
the watch window displays the uninitialized value in a color which indicates
that the variable is valid.  (Default invalid color is red.)

Bug Description

When packet transfers/external memory accesses are occurring,
clock cycles as recorded by tcount are extremely inaccurate on the
simulator.
 

Bug Description

When using the ms command on the simulator, the following error occurs when
trying to load the output file:
 
mvp1_pp0> load output.dat
Loading output.dat
Object file endianess conflicts with target
Check memory map

Bug Description

When doing a WA args on the following code, the debugger exits:
 
void ppfunc(long *args) {
  int i;
  long x,y,z;
 
  x=*args++;
  y=*args++;
  z=*args++;
 
  for(i=0;i<1;)
    ;
}

Bug Description

Exclusive Range Breakpoint Enable not working correctly with C80 emulator
version 1.10.  The emulator allows user to modify parameters for the
exclusive range breakpoint but transitions to a 'Breakpoints disabled' state
when the parameters are entered(OK'd).

Bug Description

 
If you declare a very large multidimensional array the debugger does not
handle it properly.  This is best explained with an example.  Let's say
you have the following global variable declaration in a C file.
 
#pragma DATA_SECTION( pp_data, "mysection" )
 
unsigned char pp_data[ 4 ][ 0x1c200 ];
 
You also have the following statements in your link file.
 
MEMORY
{
       MYMEM:  o=0x02600000    l = 0x00100000
}
 
SECTIONS
{
       mysection:      >MYMEM
}
 
If this is all you had in "mysection", the following expressions would
yield:
 
       &( pp_data[ 0 ][ 0 ] ) = 0x02600000
       &( pp_data[ 1 ][ 0 ] ) = 0x0261c200
       &( pp_data[ 2 ][ 0 ] ) = 0x02638400
       &( pp_data[ 3 ][ 0 ] ) = 0x02654600
 
If you type the following statements into the debugger, you will get a
different answer.
 
? &( pp_data[ 0 ][ 0 ] )       ==> 0x02600000
? &( pp_data[ 1 ][ 0 ] )       ==> 0x0260c200
? &( pp_data[ 2 ][ 0 ] )       ==> 0x02618400
? &( pp_data[ 3 ][ 0 ] )       ==> 0x02624600
 
The linker generates the correct addresses, but the debugger computes
the wrong addresses because it only uses the least significant 16 bits
of the 2nd dimension size.
 

Bug Description

Load and sload on the Workstation Debugger are unnecessarily slow.

Bug Description

Silcon Revision 3.x doesn't run at 50 Mhz

Bug Description

The keyboard shortcut "E" in the analysis menu is ambiguous.  It can mean
Exclusive Range Enable or EMU0 driven low.

Bug Description

When a breakpoint is set in a file with a very long path set with the "use"
command, listing the breakpoints with bl does not display all breakpoints.

Bug Description

Load and sload are unnecessarily slow on the PC Version 1.13.

Bug Description

Single stepping C code is too slow.

Bug Description

Typing sconfig alone is supposed to restore the screen configuration stored
in init.clr which is either in the current directory or the D_DIR
environment variable.  The PC version 1.13 does not look for the file and
returns an error if no filename is supplied.

Bug Description

When target board power is not connected, starting the debugger causes a
crash, reporting a program exception error.

Bug Description

The PC debugger's maximum window width is not wide enough to display all
PP assembly instructions.  For instance, if a PP instruction is using all
four slots (MPY, ALU, Global transfer, Local transfer), the debugger
dissassembly window cuts off the entire local slot.

Bug Description

Goto /net/magoo/home1/karen/c80hotline/take_color.sdb
 
Will fix next release

Bug Description

In the MP SDB Debugger, 2 consecutive reset commands will cause the
debugger to get a processor access timeout error.

Bug Description

Debugger displays incorrect values for double floats with the WA and
DISP commands.

Bug Description

When you set a breakpoint in one PP simulator window and disassemble
the code in another PP's simulator window, an estop is displayed
instead of the instruction.  The simulator executes the correct
instruction.

Bug Description

Using the ?HALTOVR=1 command to unhalt the PP from the simulator command
line does not work unless it is immediately followed by a step command.
It also does not work ?HALTOVR=1 executed in parallel on more than one
PP simulator.
 

Bug Description

The hex utility output files contain address discontinuities
with some address ranges not being displayed.

Bug Description

When trying to convert an object-file using the Hex Utility, sometimes
the message "Error reading coff-file" appears.
 
The following code fragments cause the Hex Utility to return the above
error:
 
 int a,b,d;
 const int c = 32768;
 a = b + c + d;
 
 int a,b,d;
 const int c = 32768;
 a = b + c;
 a = a + d;
 

Bug Description

Using the -s switch for the linker generates many relocation
symbol errors when linking relocateable object modules which
have not had symbols stripped.

Bug Description

The address of two different locations in memory is assembled
by mpasm to the same address.  The problem occurs with both PC
and workstation tools.

Bug Description

    The dlog command does not work as is explained in the UG.
 
    From a PDM command window if you type dlog filename, whatever commands
    you type in the PDM command window should get logged in the file named
    filename.  However, it looks like the entire screen is being logged,
    not just the commands.
 
    For example:
 
    From a PDM command window:
 
    PDM:1>> dlog init.pdm
    PDM:2>> spawn mpsim
    PDM:3>> send -g MP load sample
    PDM:4>> dlog close
 
    The file init.pdm is supposed to have:
 
    spawn mpsim
    send -g MP load sample
 
    However, init.pdm actually contains
 
    PDM:2> spawn mpsim
    PDM:3> send -g MP load sample
    PDM:4> dlog close

Bug Description

The PDM stat command displays IP address on the MP, IPE address on the PP,
but labels all IP addresses as PC.
 
Example:
 
[mvp1_mp] Halted  PC=FFFFFFF8
[mvp1_pp0] Halted  PC=0
[mvp1_pp1] Halted  PC=0
[mvp1_pp2] Halted  PC=0
[mvp1_pp3] Halted  PC=0

Bug Description

Example 8-27. Shifted Multiply in C8x Parallel Processor User's Guide
page PP:8-92 will not assemble and returns error:
 
ERROR! E0800: Non-zero dms permitted only with split or round multiplies
 
Example:
 
 
     d0 = DMS_EX
 
     d7 =(d6 * d5) << 2
     || ealu(DMS_EX)
 

Bug Description

Autoinitialization of data within a single .bss area
is not initialized correctly.  Values are assumed to be
aligned on the correct byte within a 4 byte initialization
record (.cinit).  Multiple initializations are actually
leftmost adjusted within a word.  Multiple values
initialized within the same word may overlay each other
and/or be placed at a wrong location within the correct
word.
 

Bug Description

The system() function defined in stdlib.h is not supported
for the mvp.  Using this function results in linker errors
since system() is not defined in the run time system libraries.
The system() function should have a dummy body supplied and
unsupported functions in standard header files documented.

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