|
|
The following is a list of all currently known Defects in the current
release of the Code Generation Tools. All defects will be
fixed in the next release unless otherwise indicated.
- Note:
- This list may contain references to internal or beta versions of
the product. So please refer to product availability list to
determine the current production revision.
Date: Fri Sep 27 19:00:00 CDT 1996
Linker
Assembler
RTS
HLL
C5xx Simulator
DEFECTS IN COMPILER V1.10
| Title: Code gen issues error "...COMPILER ERROR: no match for VREG |
| Bug # | Tool | Version | Fixed? |
| SDSsq02116 | Compiler | V1.10 | Fixed, will appear in next release. |
Bug Description
BUG DESCRIPTION
===============
The code generator may generate internal error messages:
"...COMPILER ERROR: no match for VREG" when generating
code for interrupt service routines.
Workaround/Solution
WORKAROUND/SOLUTION
===================
Although the code generator issues the error, it should
still produce code. The code should be alright with the
exception of generating code to properly save RSA and
REA registers which is noted in a seperate report. However,
you should check the generated assembly to make sure that
all registers are properly saved/restored in the ISR.
|
| Title: If command line exceeds 99 chars the compiler may fail. |
| Bug # | Tool | Version | Fixed? |
| SDSsq02683 | Compiler | V1.10 | Fixed, will appear in next release. |
Bug Description
BUG DESCRIPTION
===============
If the command line (includding both options given on command line
plus any specified by C_OPTION) exceeds 99 chars the compiler may
fail generating the error message: COMPILER ERROR : PACKET ERROR : 8
Note: This problem occurs on PC only.
Workaround/Solution
WORKAROUND/SOLUTION
===================
Reduce the length of the command line. If you are using -d options,
you can workaround by using a header file that defines the needed
symbols instead. If you are using -i option to search alternate paths
for "#include" files then use the C_DIR environment variable to
specify alternate paths.
|
| Title: Incorrect code may be gen on an assignment of a PORT var to a loc sym |
| Bug # | Tool | Version | Fixed? |
| SDSsq02859 | Compiler | V1.10 | Fixed, will appear in next release. |
Bug Description
BUG DESCRIPTION
===============
The compiler may err when generating code for an assignment
from read of a PORT variable, when the target of the assignment
is a local var whose storage space is allocated on the stack,
and whose value is subsequently used in a call to a function.
e.g.
port unsigned int port100;
func()
{ int tmp;
tmp = port100; /* incorrect address may be calculated for
store to tmp */
call(0,tmp);
}
Workaround/Solution
WORKAROUND/SOLUTION
===================
Delcare tmp at file level, rather than as a local var.
|
LINKER DEFECTS
| Title: Assembler creates bad relocation info for 2 word instr on 2048 boundary |
| Bug # | Tool | Version | Fixed? |
| SDSsq02266 | Linker | V1.10 | Fixed, will appear in next release. |
Bug Description
BUG DESCRIPTION
===============
When a two word instruction with a long constant as the second
word of the encoded instruction occurs on a 2048 word boundary
the assembler may assign incorrect relocation information for
this constant. The incorrect relocation information will cause
the linker to fail to properly relocate the constant. The constant
will have the value assigned to it by the section program counter
(SPC) within the assembler.
Workaround/Solution
WORKAROUND/SOLUTION
===================
Do aything that changes the size of the section. i.e. add
a NOP, assemble into a different section, etc.
|
ASSEMBLER DEFECTS
| Title: Assembler may not treat signed floating point constant correctly |
| Bug # | Tool | Version | Fixed? |
| SDSsq02531 | Assembler | V1.10 | Fixed, will appear in next release. |
Bug Description
BUG DESCRIPTION
===============
The assembler does not treat signed floating point constant operations
correctly in all instances.
i.e.
t2 .set -5.0
...
...
t15 .set t2*-1.0 ; incorrectly yields a negative value
Workaround/Solution
WORKAROUND/SOLUTION
===================
Will fix next release.
|
| Title: The assembler gen erroneous errors for all labels after syntax err |
| Bug # | Tool | Version | Fixed? |
| SDSsq02816 | Assembler | V1.10 | Fixed, will appear in next release. |
Bug Description
BUG DESCRIPTION
===============
There is a bug in the parser of the assembler for STH instruction
in which it fails to catch incorrect operand combination such
as appears below:
STH A, *AR4+,1
The side effect of this is that the assembler will generate
errors when processing addresses of labels that subsequently
appear in the file.
Workaround/Solution
WORKAROUND/SOLUTION
===================
Correct the syntax of the offending STH instruction.
|
RTS DEFECTS
| Title: The BOOT.ASM routine does not contain code for .const copy as advertised |
| Bug # | Tool | Version | Fixed? |
| SDSsq02813 | RTS | V1.10 | Fixed, will appear in next release. |
Bug Description
BUG DESCRIPTION
===============
The RTS C boot routine c_int0, does not contain code for copy
of .const section from program to data space as is stated
in the C compiler Users Guide (SPRU103A, Sec 4.1.3, pg 4-4).
Workaround/Solution
WORKAROUND/SOLUTION
===================
Edit the boot routine to add the following source.
1. Extract the boot routein from rts.src - source code
library.
ar500 -x rts.src boot.asm
2. Edit the routine adding the following:
Line 5 : .mmregs
Add Line 6 : CONST_COPY .set 1
Old Line 98
(NOW 99) : DONE_INIT
Add Line 100: .if CONST_COPY
Add Line 101: CALL _const_init ; move .const section to DATA mem
Add Line 102: .endif
Before Old Line 106: .end
Insert following code:
.if CONST_COPY
*** PATCH START *************************************
******************************************************
* FUNCTION DEF : __const_init *
* *
* COPY .CONST SECTION FROM PROGRAM TO DATA MEMORY *
* *
* The function depends on the following variables *
* defined in the linker command file *
* *
* __c_load ; global var containing start *
* of .const in program memory *
* __const_run ; global var containing run *
* address in data memory *
* __const_length ; global var length of .const *
* section *
* *
******************************************************
.global __const_length,__c_load
.global __const_run
_const_init:
.sect ".c_mark" ; establish LOAD adress of
.label __c_load ; .const section
.text
******************************************************
* C5xx VERSION *
******************************************************
LD #__const_length, A
BC __end_const,AEQ
STM #__const_run,AR2 ; Load RUN address of .const
RPT #__const_length-1
MVPD #__c_load,*AR2+ ; Copy .const from program to data
******************************************************
* AT END OF .CONST SECTION RETURN TO CALLER *
******************************************************
__end_const:
RET
.endif
|
HLL DEFECTS
| Title: Patchingthe instruction MVDD *ar2+, *ar3+0 , causes the core dump |
| Bug # | Tool | Version | Fixed? |
| SDSsq02722 | HLL | V0.00 | Fixed, will appear in next release. |
Bug Description
BUG DESCRIPTION
===============
When the following instruction is patch assembled in the C source debugger,
it causes the debugger to core dump when running on SUN/Sparc and produces
a protection fault when running the debugger under Windows on the PC.
i.e. MVDD *ar2+, *ar3+0 <== Patch assembly of this instruction
causes core dump.
Workaround/Solution
WORKAROUND/SOLUTION
===================
The insturction MVDD *ar2+, *ar3+0, is actually an incorrect
addressing form for the MVDD instruction. There is no workaround
for the core dump. But this should pose no problem if correct
addressing modes are used.
|
C5XX SIMULATOR DEFECTS
| Title: The simulator doesnt always display the first argument passed in a func |
| Bug # | Tool | Version | Fixed? |
| SDSsq02685 | C5xx Simulator | V2.00 | Will fix in a future release |
Bug Description
BUG DESCRIPTION
===============
The simulator does not recognize the first parameter in a
function definition. It is not possible to set a "wa", "?",
or "e" on this parameter.
i.e.
int func(first, second, third) {
...
...
}
The simulator will not recognize the symbol "first" when within
the function.
Workaround/Solution
WORKAROUND/SOLUTION
===================
No workaround currently available.
|
|
|