This appendix contains the following sections:
Introduction
Creating a Motorola COFF Object File
Using Library Function
Linking Motorola CLAS/COFF
Running Examples from EDE
This appendix describes the interoperability between the TASKING and Motorola tool sets. That means, how to create an application with the TASKING DSP56xxx C compiler, which can be debugged with the Motorola debugger; or how to link Motorola object files and library files with the TASKING linker.
The TASKING tools do not have the capability to generate objects in the Motorola CLAS COFF object format with debug information. In order to overcome this limitation it is possible to generate an assembly file with the TASKING tools, which can then be assembled with the Motorola assembler.
Generating an assembly file with the TASKING tools uses the following path:
| \ V (.c) | | c563 | | | |- cc563 (control program) V (.src) | | as563 | | | | V (.asm) /
The control program calls both the compiler and the assembler. The compiler generates a source file. This source file generated by the compiler contains COFF style debug information that will be converted by the Motorola assembler. The generated source file is taken through the TASKING assembler to further optimize this assembly code. Among the optimizations performed by the TASKING assembler are move parallelization, jump and branch optimizations and DO into REP conversion. The assembler generates an assembly file that is compatible with the Motorola assembler.
It is possible to use the source file from the compiler (.src) in the Motorola assembler directly. However, in doing so optimizations will get lost.
In order to support the generation of Motorola compatible assembly code with COFF debug information, the following command line options must be supplied to the TASKING tools:
Tool | Option |
cc563 | -S |
c563 | -Cg |
as563 | -S |
The -S option tells the 563xx control program to generate a Motorola compatible assembly file. It does so by taking the following steps:
1. call the compiler with the -C1 option (full Motorola compatibility mode)
2. call the assembler with the -S option (generate an assembly file instead of an object file)
The control program stops after generating the assembly file. The linker and locator will not be invoked. The generated assembly file is generated by default by adding a .asm extension to the input file. You can specify the name of the generated assembly file with the -o option of the control program.
If, for any reason, you do not want to use the full compatibility mode, you have to specify the compiler and assembler options yourself. For instance:
cc563 -g -Wc-Cg -Wa-S -c -o file.asm file.c
will only generate COFF debug information, but will skip the other compatibility options.
The -Cg option tells the compiler to generate COFF style debug information instead of the normal SYMB directives. The COFF debug information is only generated when the -g option is specified as well. It is highly advisable to use the -Ca option as well in order to generate Motorola assembler compatible output.
When using the -Ca option it is not possible
to use packed strings. The _packed keyword will then be ignored.
The -S option instructs the assembler to generate an assembly file instead of an object file. It is still possible to generate a list file as well.
Using the assembler for optimization can result in synchronization loss between the generated code and the debugging information. Using the -OG option will prevent this,
but has negative effects on the optimization performed.
This example compiles the file demo.c with the TASKING compiler, and uses the Motorola assembler and linker to generate the final COFF absolute file. The -g switch is given in order to get debug information.
cc563 -S -g demo.c g563c demo.asm -g -o demo.cld -mx-memory
or if you do not want to use the different control programs:
c563 -g -C1 demo.c as563 -S demo.src asm56300 -c -Bdemo.cln demo.asm dsplnk -g -c -Bdemo.cld crt0563x.cln demo.cln -Llib563cx.clb
The same examples, now using Y memory:
cc563 -S -g -My demo.c g563c demo.asm -g -o demo.cld
or
c563 -C1 -g -My demo.c as563 -S demo.src asm56300 -c -Bdemo.cln demo.asm dsplnk -g -c -Bdemo.cld crt0563y.cln demo.cln -Llib563cy.clb
The Motorola assembler needs the -c option
in order to work correctly.
- Packed strings are not supported when generating Motorola compatible assembly. The _packed keyword is ignored because the Motorola assembler does not have directives to support this.
- The TASKING tools can move variables around between registers and/or stack in order to get optimal code. To allow the debugger to keep track of these moves the compiler generates lifetime information, telling the debugger in which register the variable is located. The COFF debug format cannot handle lifetime information. Therefore, this information is lost. Watching an automatic variable in a debugger could result in looking at the wrong place. This problem can be overcome by turning off the optimizations with -O0.
- The default memory model for the TASKING tools is X memory. The Motorola tools use Y memory. You need to specify another memory model for one of the tool chains. You can either specify the -My option to the TASKING control program for generating programs which use Y memory, or you can specify the -mx-memory option to the Motorola control program.
The COFF libraries as supplied with the Tasking tools
use the X memory.
- Floating point variables generated by the Motorola C compiler have a format that differs from the TASKING format. Restrict the use of floating point variables to one compilation system.
Due to certain differences between the TASKING compiler and the Motorola compiler it is normally not possible to use the standard Motorola libraries with COFF objects generated with the TASKING tools. Therefore, the TASKING libraries are supplied in both IEEE object format and in COFF object format. These COFF libraries fully support Motorola's file system support. The libraries support the 563xx in 24-bit mode (librt24.clb, libfp24.clb, libc24.clb), the 566xx (librt6.clb, libfp6.clb, libc6.clb) and the 5600x (librt.clb, libfp.clb, libcm.clb, libcs.clb, libcr.clb).
Even when using the TASKING COFF libraries it is necessary to use the crt0 startup files as provided by Motorola. This is necessary because this file contains numerous variables that are filled in by the Motorola linker.
When using the malloc() functions from the TASKING COFF libraries, you must use a linker memory control file in order to specify the heap. Normally theTASKING linker/locator allocates the heap and generates symbols for the start and end of it.. You have to specify the symbols F_lc_bh and F_lc_eh, where F_lc_bh indicates the beginning of the heap area and the F_lc_eh the end of the heap area.
The heap must reside in default memory space.
An example of a memory control file is given here:
reserve y:$3000..$3fff symbol F_lc_bh y:$3000 symbol F_lc_eh y:$4000
This will define the Y memory from $3000 till $4000 as heap space which the malloc() routine can use for allocating memory.
The TASKING linker has the capability to read in Motorola CLAS/COFF object files and library files. It will convert debug information in these files into that of the TASKING IEEE-695 object format. This allows debugging a program compiled with the Motorola tools with CrossView Pro.
The TASKING linker looks at the filename extension to determine what kind of input file it is. In order for the linker to recognize a file as a Motorola CLAS/COFF file the file must have the extension .cln. A Motorola CLAS/COFF library file must have the extension .clb.
This example links the CLAS COFF object file util.cln with the program prog.c. The Motorola library is specified as well in order to resolve any run-time routines which might be called from util.cln. The control program automatically links with the TASKING libraries.
cc563 -g prog.c util.cln lib563x.clb
- The Motorola linker/locator uses internally defined symbols like DSIZE. This symbol defines the beginning of the dynamic stack. The TASKING linker/locator does not know the DSIZE symbol. Therefore, this will remain an unresolved symbol. This will only happen if you link with the Motorola startup code (crt0563x.cln). Use the TASKING startup code instead.
- The TASKING libraries are translated with a different calling convention than the Motorola compiler uses. So, any calls to a TASKING library function from a program compiled by the Motorola compiler will fail. It is possible to recompile the libraries with the -Ccr option to create libraries that use the Motorola calling convention.
- The TASKING libraries are compiled for using X memory by default. The Motorola compiler generates programs that use Y memory by default. Either recompile all the TASKING libraries for Y memory (-My), or specify -mx-memory to the Motorola tools.
The TASKING DSP56xxx toolchain now provides a special EDE file to generate code in Motorola COFF format with debug information. The following installation steps are necessary to allow this to work:
1. Install the Motorola executables (at least the assembler and linker, and optionally the debugger) in a single directory. Add the path to this directory to the PATH environment variable, as prescribed by the Motorola installation instructions (adding it to Project | Directories | Executable Files Path will not work).
2. In the Project | Select Toolchain... dialog, select the correct toolchain that is shown as "with Motorola tools". The Project | Project Options... dialog will now show options for the Motorola tools instead of the TASKING linker and locator. To revert to the TASKING tools later, select the correct toolchain without the additional "with Motorola tools".
3. Add the path to the Motorola library directory to Project | Directories | Library Files Path to allow the tools to find the Motorola startup files.
4. Select an EDE option, for instance Project | Project Options | Motorola Debugger, and press OK to force the tools to rebuild the makefile.
5. Press the Rebuild button to build the project.
6. Press the Debug button to start the Motorola debugger. The debugger will automatically load the executable.
7. To run an example that writes to stdout, like "hello world", enter the following commands on the debugger command line:
streams enable redirect stdout file.txt go
8. The output of the program can now be found in file.txt in the current working library.
This method works for the 'hello','sieve' and 'whet' examples. For the 'dhry_1' and 'dhry_2' examples, a linker control file must be added to the project to create a heap for the malloc() function. The following contents can be used for this file, but it may require changes for different memory sizes on actual hardware:
reserve x$2000..$3fff symbol F_lc_bh x:$2000 symbol F_lc_eh x:$3000
Add the linker control file to the linker options with the -Rfilename command. Running the examples in the bench directory may take a very long time on the simulator. Other examples cannot be run because they contain assembly files that are not Motorola compliant.