This chapter contains the following sections:
Introduction to DSP56xxx Family C Cross-Compiler
General Implementation
Compiler Phases
Frontend Optimizations
Backend Optimizations
Specific Optimizations
Replacing NOPs
Instruction Parallelization (parallel moves)
Hardware DO and REP Loops
Bitfields
MAC Instruction Generation
Absolute Addressing Mode Usage
Sample Session
Using EDE
Using the Control Program
Using the Makefile
This manual provides a functional description of the TASKING DSP56xxx Family C Cross-Compiler. This manual uses c563 (the name of the binary) as a shorthand notation for "TASKING DSP563xx/DSP566xx C Compiler", and uses c56 as a shorthand notation for "TASKING DSP5600x C Compiler".
TASKING offers a complete toolchain for the Motorola DSP56xxx Family of Digital Signal Processors (DSPs) and their derivatives. The DSP563xx (24-bit), the DSP566xx (16-bit), the DSP5600x (24-bit) family are supported. This manual uses 'DSP5600x' to indicate the derivatives that have a '0' in the third position (e.g. DSP56002), 'DSP563xx' for those that have a '3' in the third position (e.g. DSP56366) and 'DSP566xx' along the same lines. In this manual all core versions are treated identical unless implementation differences require otherwise. 'DSP56xxx' is used as a shorthand notation for the Motorola DSP56xxx Family of Digital Signal Processors (DSPs) and their derivatives. The toolchain contains a C++ compiler, a C compiler, an assembler, a linker, a locator, a control program, a make utility, a library maintainer, an object reader utility and a debugger.
The C compilers are dedicated to the DSP architecture of the DSP56xxx. This means that you can access all special features of the DSP56xxx in C. And yet the C compiler conforms to the ANSI standard. It is a single pass, optimizing compiler that generates fast and compact code.
c563 generates assembly source code using the DSP563xx or DSP566xx assembly language specification. You must assemble this code with the TASKING DSP563xx Cross-Assembler. This manual uses as563 as a shorthand notation for "TASKING DSP563xx/DSP566xx Cross-Assembler".
c56 generates assembly source code using the DSP5600x assembly language specification. You must assemble this code with the TASKING DSP5600x Cross-Assembler. This manual uses as56 as a shorthand notation for "TASKING DSP5600x Cross-Assembler".
You can link the generated object with other objects and libraries using the TASKING DSP563xx/DSP566xx linker. In this manual we use lk563 as a shorthand notation for "TASKING DSP563xx/DSP566xx linker". You can also link Motorola COFF objects and libraries with lk563. You can locate the linked object to a complete application using the TASKING DSP563xx/DSP566xx locator. In this manual we use lc563 as a shorthand notation for "TASKING DSP563xx/DSP566xx locator". Use lk56 and lc56 for the DSP5600x linker and locator.
The DSP56xxx toolchain also accepts C++ source files. C++ source files or sources using C++ language features need to be preprocessed by cp563 (DSP563xx/DSP566xx), cp56 (DSP5600x). The output generated by cp563 is DSP563xx or DSP566xx C, which can be translated with the C compiler c563. The output generated by cp56 is DSP5600x C, which can be translated with the C compiler c56.
Note that the C++ compilers are not part of the C compiler package. They can be ordered separately from TASKING.
The programs cc56, and cc563 are control programs for the DPS5600x, and DSP563xx/DSP566xx respectively. The control program facilitates the invocation of various components of the DSP56xxx toolchain. cc563 recognizes several filename extensions. C++ source files (.cc, .cxx or .cpp) are passed to the C++ compiler. C source files (.c) are passed to the compiler. Assembly sources (.asm or .src) are passed to the assembler. Relocatable object files (.obj) and libraries (.a) are recognized as linker input files. Files with extension .out and .dsc are treated as locator input files. The control program supports options to stop at any stage in the compilation process and has options to produce and retain intermediate files.
You can debug the software written in C with the TASKING CrossView Pro high-level language debugger. A list of supported platforms and emulators is available from TASKING.
In this manual c563, as563, lk563, lc563, cc563, mk563, ar563 and pr563 are used to indicate the executables of both DSP56xxx toolchains, unless explicitly stated otherwise.
This section describes the different phases of the compiler and the target independent optimizations.
During the compilation of a C program, a number of phases can be identified. These phases are divided into two groups, referred to as frontend and backend.
The preprocessor phase:
The scanner phase:
The parser phase:
The frontend optimization phase:
The backend optimization phase:
The code generator phase:
The peephole optimizer / pipeline scheduler phase:
All phases (of both frontend and backend) of the compiler are combined into one program. The compiler does not use intermediate files for communication between the different phases of compilation. The backend part is not called for each C statement, but starts after a complete C function has been processed by the frontend (in memory), thus allowing more optimization. The compiler only requires one pass over the input file, resulting in relatively fast compilation.
The command line option -O controls the amount of optimization applied on the C source. Within a source file, the pragma #pragma optimize sets the optimization level of the compiler. Using the pragma, certain optimizations can be switched on or off for a particular part of the program. Several optimizations cannot be controlled individually, for example, constant folding will always be done.
The compiler performs the following optimizations on the intermediate code. They are independent of the target processor and the code generation strategy:
Expressions only involving constants are replaced by their result.
Expressions are rearranged to allow more constant folding. E.g. 1+ (x-3) is transformed into x + (1-3), which can be folded.
Multiplication by 0 or 1 and additions or subtractions of 0 are removed. Such useless expressions may be introduced by macros, or by the compiler itself (e.g., array subscription).
Expressions involving '&&', '||' and '!' are interpreted and translated into a series of conditional jumps.
With for and while loops, the expression is evaluated once at the 'top' and then at the 'bottom' of the loop. This optimization does not save code, but speeds up execution.
A number of optimizations of a switch statement are performed, such as the deletion of redundant case labels or even the deletion of the switch.
By reversing jump conditions and moving code, the number of jump instructions is minimized. This reduces both the code size and the execution time.
A conditional or unconditional jump to a label which is immediately followed by an unconditional jump may be replaced by a jump to the destination label of the second jump. This optimization does not save code, but speeds up execution.
An unconditional jump to a label directly following the jump is removed. A conditional jump to such a label is replaced by an evaluation of the jump condition. The evaluation is necessary because it may have side effects.
A conditional jump over an unconditional jump is transformed into one conditional jump with the jump condition reversed. This reduces both the code size and the execution time.
Identical code sequences in two different execution paths are merged when this is possible without adding extra instructions. This transformation decreases code size rather than execution time, but under certain circumstances it avoids the execution of one jump.
A reference to a variable with known contents is replaced by those contents.
The compiler has the ability to detect repeated uses of the same (sub-) expression. Such a "common" expression may be temporarily saved to avoid recomputation. This method is called common subexpression elimination, abbreviated CSE.
Unreachable code can be removed from the intermediate code without affecting the program. However, the compiler generates a warning message, because the unreachable code may be the result of a coding error.
Invariant expressions may be moved out of a loop and expressions involving an index variable may be reduced in strength.
The following optimizations are target dependent and are therefore performed by the backend.
Variables, parameters, intermediate results and common subexpressions are represented in allocation units. Per function, the compiler builds a graph of allocation units which indicates which units are needed and when. This allows the register allocator to get the most efficient occupation of the available registers. The compiler uses the allocation graph to generate the assembly code.
The generated assembly code is improved by replacing instruction sequences by equivalent but faster and/or shorter sequences, or by deleting unnecessary instructions.
Leaf functions (function not calling other functions), are handled specially with respect to stack frame building.
Try to duplicate a loop body 2, 4 or 8 times to reduce the number of branches and to create a longer linear code part. This optimization is only performed when hardware loops are not possible.
Expressions from which the result is never used are eliminated.
Where possible replace loops in the program by the zero-overhead hardware loop supported by the DSP.
Improving generated assembly code by replacing operands, e.g. replace an immediate value with a register that contains that value already.
Besides the common optimizations, some special optimizations are performed. These optimizations are specific for each DSP56xxx family. The compiler supports an optimization method that allows instruction re-ordering and parallelization of instructions.
In some cases the contents of an address register are not available in the next instruction due to pipeline effects. In such cases, the compiler generates a NOP instruction. The assembler tries to replace these NOPs with other instructions when possible. The compiler enables the NOP optimization of the assembler by generating an OPT directive in the assembly source.
In general, one or two moves can be performed together with an arithmetic instruction, which are called 'parallel moves'. The parallel moves are restricted by the addressing mode used, and not all arithmetic instructions can have all possible parallel moves. In this manual a place where a parallel move can be performed is called a 'move slot'. If there is an arithmetic instruction without a parallel move, you can see this as an 'empty move slot'.
The compiler does not generate parallel moves. So, all move slots are empty. The assembler tries to fill up the move slots as efficiently as possible. The compiler enables the parallel move optimization of the assembler by generating an OPT directive in the assembly source.
Typical DSP applications often processes data in loops. The available hardware loop instruction supports fast loops. It is important to have a compiler that generates loops as fast as possible, by making use of the hardware loop instructions and by making use of the parallel move capability of the DSP. The actual hardware DO to REP optimization is performed by the assembler. See also the section Optimizations of the chapter Assembler in the DSP56xxx Cross-Assembler User's Guide.
Take for instance the next C fragment:
_fract fir_filter(_fract data[], _fract _Y coef[]) { long _fract result; int i; result = 0.0; for ( i = 0; i < 100; i++ ) { result += data[i] * (long _fract) coef[i]; } return _round(result); }
The loop is recognized as a simple loop and the array references are interpreted as post increment pointers. The code will be internally rewritten by the compiler as:
result = 0.0; tmp1 = data; tmp2 = coef; for ( i = 0; i < 100; i++ ) { result += *tmp1++ * *tmp2++; }
Because of the very powerful addressing modes of the DSP families the pointer dereference and the auto-increment are easy to implement. The index i is not used anymore and will be optimized away. The compiler generates assembly code similar to the following code (the last column gives the code size in words and the execution time in clock cycles):
clr a ; Clear result 1,1 do #100,L5 ; Hardware do loop 2,5 move x:(r0)+,x0 ; Get an element of 'data' 1,1* move y:(r4)+,y0 ; Get an element of 'coef' 1,1* mac x0,y0,a ; Multiply and accumulate 1,1* L5: void x0, y0, r0, r4 ; End of loop, indicate registers ; unused after loop rnd a ; Round result 1,1 rts ; Return it 1,3
This results in a loop time of only 3 clock cycles! (The instructions within the loop are marked with an '*' after the size/timing figures.) But, the empty move slot(s) are not yet used. The problem is that X0 and Y0 must be known at the start of the mac instruction. It is possible to retrieve these values after the mac instruction for the next loop incarnation if the first values are obtained before the loop:
clr a ; Clear result 1,1 move x:(r0)+,x0 ; Get first element of 'data' 1,1 move y:(r4)+,y0 ; Get first element of 'coef' 1,1 do #100,L5 ; Hardware do loop 2,5 mac x0,y0,a ; Multiply and accumulate 1,1* move x:(r0)+,x0 ; Get next element of 'data' 1,1* move y:(r4)+,y0 ; Get next element of 'coef' 1,1* L5: void x0, y0, r0, r4 ; End of loop, indicate registers ; unused after loop rnd a ; Round result 1,1 rts ; Return it 1,3
At first sight, this code is not better. However, after applying the optimization of the assembler to put instructions in parallel, the result becomes:
clr a x:(r0)+,x0 y:(r4)+,y0 ; Clear result, 1,1 ; prime loop do #100,L5 ; Hardware do loop 2,5 mac x0,y0,a x:(r0)+,x0 y:(r4)+,y0 ; Multiply and 1,1* ; accumulate, and get ; next elements of 'data' L5: ; and `coef' rnd a ; Round result 1,1 rts ; Return it 1,3
In this final result, the loop time is one instruction cycle, the absolute minimum. The hardware loop instruction 'do' can be replaced by a 'rep' because there is only one instruction left within the loop.
The optimization of DO to REP loops can be controlled with the -OR/-Or command line option of the compiler. This option can also be used with the #pragma optimize to turn the optimization on or off for some code parts.
#pragma optimize R /* turn DO to REP optim off */ for( ... ) /* some loop */ #pragma optimize r /* turn DO to REP optim on */
The compiler will not use a hardware loop when:
When one of these criteria is met the compiler generates loops that consist of branch and jump instructions, which make it possible to do some optimizations not possible on hardware DO loops.
The nesting depth of hardware DO loops can be controlled with the -L command line option as each loop takes two hardware stack loads. Counting the nesting is restricted to one function level. Unless hardware stack extension is enabled, loops containing a function call will not be implemented as hardware loops. The compiler cannot determine the hardware stack use of the called function and must avoid exhausting it.. When the stack depth is exceeded, the compiler will not generate hardware DO loops for the highest levels.
The compiler is called as follows:
c563 -L4 example.c
The code in example.c is:
for( ... ) /* depth 1 -> no hardware DO loop */ { for( ... ) /* depth 2 -> hardware DO loop */ { /* stack level 2 */ for( ... ) /* depth 3 -> hardware DO loop */ { /* stack level 4 */ ... } } }
The DSP56xxx instruction set contains several instructions to do fast operations on a single bit. The c563 C compiler will use these functions for operations on bitfields.
struct { unsigned int b :1; } a; a.b = 1;
Generated code:
. . bset #0,x:Fa . .
Where Fa is the start address of the structure.
The compiler will generate the multiply-accumulate instructions for multiplications whenever possible and useful. See section 2.2.4.3, Hardware DO and REP Loops, for an example.
For accessing static and global objects the compiler will use absolute addressing modes whenever possible. When the object is defined as _near (see section Storage Specifiers) the compiler will use short addressing modes when the used instruction has such an addressing mode.
If you want to build a DSP56xxx application you need to invoke the following programs directly, or via the control program:
You can directly load the output file of the locator with extension .abs into the CrossView Pro debugger.
The next figure explains the relationship between the different parts of the TASKING DSP563xx toolchain:
Figure 2-1: DSP563xx development flow
For the DSP5600x toolchain, each executable name ends in '56'.
The next figure explains the relationship between the different parts of the TASKING DSP563xx toolchain and the Motorola toolchain. This path is active when the -S option of cc563 is used, or when the tool set with Motorola tools is selected in EDE.
Figure 2-2: Motorola toolchain connection
The program cc563 is a so-called control program, which facilitates the invocation of various components of the DSP56xxx toolchain. C++ source programs are compiled by the C++ compiler, C source programs are compiled by the compiler, assembly source files are passed to the assembler. A C preprocessor program is available as an integrated part of the C compiler. The control program recognizes the file extensions .a and .obj as input files for the linker. The control program passes files with extensions .out and .dsc to the locator. All other files are considered to be object files and are passed to the linker. The control program has options to suppress the locating stage (-cl), the linker stage (-c) or the assembler stage (-cs).
Optionally the locator, lc563 produces output files in Motorola S-record format, Motorola CLAS compatible object format or Intel Hex format. The default output format is IEEE-695.
Normally, the control program removes intermediate compilation results, as soon as the next phase completes successfully. If you want to retain all intermediate files, the option -tmp prevents removal of these files.
For a description of all utilities available and the possible output formats of the locator, see the DSP56xxx Cross-Assembler User's Guide.
The name of the DSP56xxx CrossView Pro Debugger is xfw56x.
This section contains an overview of the environment variables used by the DSP56xxx toolchain.
Environment Variable | Description |
AS56INC | Specifies an alternative path for include files for the assembler as56. |
AS563INC | Specifies an alternative path for include files for the assembler as563. |
C56INC | Specifies an alternative path for #include files for the C compiler c56. |
C563INC | Specifies an alternative path for #include files for the C compiler c563. |
C56LIB | Specifies a path to search for library files used by the linker lk56. |
C563LIB | Specifies a path to search for library files used by the linker lk563. |
CC56BIN | When this variable is set, the control program, cc56, prepends the directory specified by this variable to the names of the tools invoked. |
CC563BIN | When this variable is set, the control program, cc563, prepends the directory specified by this variable to the names of the tools invoked. |
CC56OPT | Specifies extra options and/or arguments to each invocation of cc56. The control program processes the arguments from this variable before the command line arguments. |
CC563OPT | Specifies extra options and/or arguments to each invocation of cc563. The control program processes the arguments from this variable before the command line arguments. |
LM_LICENSE_FILE | Identifies the location of the license data file. Only needed for hosts that need the FLEXlm license manager. |
PATH | Specifies the search path for your executables. |
TMPDIR | Specifies an alternative directory where programs can create temporary files. Used by c56, c563, cc56, cc563, as56, as563, lk56, lk563, lc56, lc563, ar56, ar563. |
Table 2-1: Environment variables
The subdirectory c in the examples subdirectory contains a demo program for the DSP56xxx toolchain.
In order to debug your programs, you will have to compile, assemble, link and locate them for debugging using the TASKING DSP56xxx tools. You can do this with one call to the control program or you can use EDE, the Embedded Development Environment (which uses a project file and a makefile) or you can call the makefile from the command line.
EDE stands for "Embedded Development Environment" and is the MS-Windows oriented Integrated Development Environment you can use with your TASKING toolchain to design and develop your application.
To use EDE on the calc demo program in the subdirectory c in the examples subdirectory of the DSP56xxx product tree follow the steps below. This procedure is outlined as a guide for you to build your own executables for debugging.
You can launch EDE by double-clicking on the EDE shortcut on your desktop.
This will launch the EDE.
The EDE screen provides you with a menu bar, a toolbar (command buttons) and one or more windows (for example, for source files), a status bar and numerous dialog boxes.
EDE supports all the TASKING toolchains. When you first start EDE, the correct toolchain of the product you purchased is selected and displayed in the title of the EDE desktop window.
If you have more than one TASKING product installed and you want to change toolchains, do the following::
1. From the Project menu, select Select Toolchain...
The Select Toolchain dialog appears.
2. Select the toolchain you want. You can do this by clicking on a toolchain in the Toolchains list box and click OK.
If no toolchains are present, use the Browse... or Scan Disk... button to search for a toolchain directory. Use the Browse... button if you know the installation directory of another TASKING product. Use the Scan Disk... button to search for all TASKING products present on a specific drive. Then return to step 2.
Follow these steps to open an existing project:
1. From the Project menu, select Set Current ->.
2. Select the project file to open. For the calc demo program select the file calc.pjt in the subdirectory c in the examples subdirectory of the DSP56xxx product tree. If you have used the defaults, the file calc.pjt is in the directory c:\c563\examples\c for the DSP563xx/DSP566xx (c56 for the DSP5600x).
The next two steps are not needed for the demo program because the files calc.c and makefile are already open. To load the file you want to look at.
1. From the Project menu, select Load Files...
The Choose Project Files to Edit dialog appears.
2. Choose the file(s) you want to open by clicking on it. You can select multiple files by pressing the <Ctrl> or <Shift> key while you click on a file. With the <Ctrl> key you can make single selections and with the <Shift> key you can select everything from the first selected file to the file you click on. Then click OK.
This launches the file(s) so you can edit it (them).
1. From the Project menu, select Directories....
The Directories dialog appears.
2. Check the directory paths for programs, include files and libraries. You can add your own directories here, separated by semicolons.
3. Click OK.
The next step is to compile the file(s) together with its dependent files so you can debug the application. But first you need to specify for which CPU type you want to build your application:
1. From the Project menu, select Project Options...
The Project Options dialog box appears.
2. Select CPU Selection.
3. In the CPU family/type box, select the CPU or CPU family for which you want to build your application and click OK.
Now you can build your application.
Steps 1 and 2 are optional. Follow these steps if you want to specify additional build options such as to stop the build process on errors and to keep temporary files that are generated during a build.
1. From the Build menu, select Options...
The Build Options dialog appears.
2. Make your changes and press the OK button.
3. From the Build menu, select Scan All Dependencies.
4. Click on the Execute 'Make' command button. The following button is the execute Make button which is located in the ribbon bar.
If there are any unsaved files, EDE will ask you in a separate dialog if you want to save them before starting the build.
Once the files have been processed you can inspect the generated messages in the Output window.
You can see which commands (and corresponding output captured) which have been executed by the build process in the Build tab:
TASKING program builder vx.yrz Build nnn SN 00000000 Compiling "calc.c" Assembling "calc.src" Linking to "calc.out" Creating IEEE-695 absolute file "calc.abs"
Once the files have been compiled, assembled, linked, located and formatted they can be executed by CrossView Pro.
To start CrossView Pro:
1. Click on the Debug application button. The following button is the Debug application button which is located in the toolbar.
CrossView Pro is launched. CrossView Pro will automatically download the compiled file for debugging.
You must tell CrossView Pro which program you want to debug. To do this:
1. From the File menu, select Load Symbolic Debug Info...
The Load Symbolic Debug Info dialog box appears.
2. Click Load.
To view your source while debugging, the Source Window must be open. To open this window:
1. From the View menu, select Source | Source lines.
The source window opens.
Before starting execution you have to reset the target system to its initial state. The program counter, stack pointer and any other registers must be set to their initial value. The easiest way to do this is:
2. From the Run menu, select Reset Target System.
To run your application step-by-step:
3. From the Run menu, select Animate.
The program calc.abs is now stepping through the high level language statements. Using the toolbar or the menu bar you can set breakpoints, monitor data, display registers, simulate I/O and much more. See the CrossView Pro Debugger User's Guide for more information.
When you first use EDE you need to setup a project space and add a new project:
1. From the File menu, select New Project Space...
The Create a New Project Space dialog appears.
2. Give your project space a name and then click OK.
The Project Properties dialog box appears.
3. Click on the Add new project to project space button.
The Add New Project to Project Space dialog appears.
4. Give your project a name and then click OK.
The Project Properties dialog box then appears for you to identify the files to be added.
5. Add all the files you want to be part of your project. Then press the OK button. To add files, use one of the 3 methods described below.
The new project is now open.
6. From the Project menu, select Load Files... to open the files you want on your EDE desktop.
EDE automatically creates a makefile for the project. EDE updates the makefile every time you modify your project.
A detailed description of the process using the sample program calc.c is described below for the DSP563xx/DSP566xx. For the DSP5600x use cc56 where cc563 is used. This procedure is outlined as a guide for you to build your own executables for debugging.
1. Make the subdirectory c of the examples directory the current working directory.
2. Be sure that the directory of the binaries is present in the PATH environment variable.
3. Compile, assemble, link and locate the modules using one call to the control program cc563:
cc563 -g -M calc.c -o calc.abs
The -g option specifies to generate symbolic debugging information. This option must always be specified when debugging with CrossView Pro.
Some optimizations may affect the ability to debug the code in a high level language debugger. Therefore, the -O2 option is automatically selected with -g to switch off these optimizations. When the -g option is specified to the compiler with a higher optimization level, the compiler will issue warning message W555.
The -M option specifies to generate map files.
The -o option specifies the name of the output file.
The command in step 3 generates the object file calc.obj, the locator map file calc.map and the absolute output file calc.abs. The file calc.abs is in the IEEE Std. 695 format, and can directly be used by CrossView Pro. No separate formatter is needed.
Now you have created all the files necessary for debugging with CrossView Pro with one call to the control program.
If you want to see how the control program calls the compiler, assembler, linker and locator, you can use the -v0 option or -v option. The -v0 option only displays the invocations without executing them. The -v option also executes them.
cc563 -g -M calc.c -o calc.abs -v0
The control program shows the following command invocations without executing them (UNIX output):
+ c563 -o /tmp/cc7208b.src -g -M24x calc.c + as563 -o calc.obj -gs -M24x /tmp/cc7208b.src + lk563 -o/tmp/cc7208c.out -ddef_targ.dsc -uR_def_targ calc.obj -lc24 -lfp24 -lrt24 + lc563 -ocalc.abs -ddef_targ.dsc -f1 -M /tmp/cc7208c.out
The -M24x option of the compiler selects the 24-bit memory model with default data space in X memory. The -lc24, -lfp24 and -lrt24 options of the linker specify to link the appropriate C library, floating point library and run-time library.
As you can see, the tools use temporary files for intermediate results. If you want to keep the intermediate files you can use the -tmp option. The following command makes this clear.
cc563 -g -M calc.c -o calc.abs -v0 -tmp
This command produces the following output:
+ c563 -o calc.src -g -M24x calc.c + as563 -o calc.obj -gs -M24x calc.src + lk563 -ocalc.out -ddef_targ.dsc -uR_def_targ calc.obj -lc24 -lfp24 -lrt24 + lc563 -ocalc.abs -ddef_targ.dsc -f1 -M calc.out
As you can see, if you use the -tmp option, the assembly source files and linker output file will be created in your current directory also.
Of course, you will get the same result if you invoke the tools separately using the same calling scheme as the control program.
As you can see, the control program automatically calls each tool with the correct options and controls.
The subdirectories in the examples directory each contain a makefile which can be processed by mk563. Also each subdirectory contains a readme.txt file with a description of how to build the example.
To build the calc demo example follow the steps below. This procedure is outlined as a guide for you to build your own executables for debugging.
1. Make the subdirectory c of the examples directory the current working directory.
This directory contains a makefile for building the calc demo example. It uses the default mk563 rules.
2. Be sure that the directory of the binaries is present in the PATH environment variable.
3. Compile, assemble, link and locate the modules using one call to the program builder mk563:
mk563
This command will build the example using the file makefile.
To see which commands are invoked by mk563 without actually executing them, type:
mk563 -n -a
The option -a causes all files to be
rebuild, regardless wether they are out of date or not.
This command produces the following output:
TASKING DSP563xx/6xx program builder vx.yrz Build nnn Copyright 1996-year Altium BV Serial# 00000000 cc563 -g calc.c -o calc.abs cc563 -cs -gn -s intrnsic.c cc563 -cs -gn -s intrpt.c
The -g option in the makefile is used to instruct the C compiler to generate symbolic debug information. This information makes debugging an application written in C much easier to debug.
The -o option specifies the name of the output file.
To remove all generated files type:
mk563 clean