ADSP Family Development Tools Release Note

Transcription

1 ADSP Family Development Tools Release Note for 3.3 PC Release UNIX Release Copyright 1997 Analog Devices, Inc. #

2 1 GENERAL INFORMATION DOCUMENTATION CONTENTS OF ADSP FAMILY DEVELOPMENT TOOLS SOFTWARE REGISTRATION FOR TECHNICAL ASSISTANCE WARRANTY SALES PACKAGE SOFTWARE INSTALLATION PC VERSION PC Requirements PC Installation Procedure for Windows PC Environment Variables SUN VERSION Sun Requirements Sun Installation Procedure Sun Environment Variables CHANGES FROM PREVIOUS RELEASE BINARY EXECUTABLES DIRECTORY ASSEMBLER ASSEMBLY RUN-TIME LIBRARY LOADER Introduction Selecting The Booting Mode Switches LINKER LIBRARIAN SIMULATORS EMULATOR SPLITTER C LANGUAGE TOOLS G21K Compiler Driver G21K Preprocessor G21K Optimizing C Compiler G21K Run Time Library Compactor COFF TOOLS CSWAP CDUMP RESTRICTIONS ASSEMBLER ASSEMBLY RUN-TIME LIBRARY LINKER LOADER LIBRARIAN SIMULATORS PC Version Restrictions...23 Copyright 1997 Analog Devices, Inc. #

3 ii 5.7 EMULATOR Restrictions ADSP-21010/ADSP EZ-ICE Specific Restrictions SHARC Software EZ-ICE Specific Restrictions SHARC Hardware EZ-ICE Specific Restrictions SPLITTER C LANGUAGE TOOLS G21K Driver G21K Preprocessor G21K Optimizing C Compiler G21K Run Time Library Compactor COFF TOOLS CSWAP CDUMP...29 APPENDIX A: ADSP-2106X COMPACTOR REFERENCE MANUAL...30 A.1 GENERAL INFORMATION...30 A.1.1 Introduction...30 A.1.2 Optimizations Performed...30 A.1.3 Basic Blocks...30 A.1.4 Calling Conventions...31 A.1.5 gco Code Optimization...31 A.2 USING THE COMPILER...32 A.2.1 Invocation...32 A.2.2 Code Options...33 A.2.3 Suggestions for Using gco...33 A.2.4 Status Report...35 Page ii

4 1 GENERAL INFORMATION 1.1 Documentation To order additional copies of any of the following publications, contact an Analog Devices sales agent. Documentation for use with this release includes the following: ADSP Family Assembler Tools and Simulator Manual ADSP Family C Tools Library Manual ADSP Family C Runtime Library Manual ADSP Family JTAG EZ-ICE User s Guide & Reference ADSP Family 3.3 Release Note ADSP-2106x Compactor Reference Manual ADSP-21020/ADSP User s Manual ADSP-2106x SHARC User s Manual 1.2 Contents of ADSP Family Development Tools This release note contains information on the following software development tools for ADSP Family DSP microprocessors that is not described in, or has changed from, the descriptions in the corresponding user s manuals. Assembler Linker Librarian Simulator Emulator (EZ-ICE In-Circuit Emulator) PROM Splitter Loader CSWAP CDUMP G21K Optimizing C Compiler G21K C Runtime Library Compactor 1.3 Software Registration We can better support you if you register. Please register your software by returning the enclosed registration form. SHARC, EZ-ICE, EZ-LAB, and the SHARC logo are registered trademarks of Analog Devices, Inc. Microsoft and Windows are registered trademarks, and Windows NT is a trademark of Microsoft Corporation. Sun Microsystems, Sun, Sun-04, SunOS, Solaris, and OpenWindows are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SPARC trademarks are trademarks or registered trademarks of SPARC International, Inc. in the United States and other countries. All other brand and product names are trademarks or registered trademarks of their respective organizations. Copyright 1997 Analog Devices, Inc. #

5 1.4 For Technical Assistance Analog Devices Computer Products Division customer support staff is available to assist with your DSP installation or usage questions. Contact customer support as follows: Call (800) ANALOG-D to reach the Analog Devices automated customer support hotline. Call (617) in Norwood, Massachusetts, USA, for applications engineering or marketing information. Send application questions by to: or to the European center at Send application or marketing questions by FAX to: (617) , or FAX questions to our European center at Send application or marketing questions by mail to the following address: Analog Devices, Inc. Computer Products Division Attention: Customer Support One Technology Way, P.O. Box 9106 Norwood, MA USA Contact customer support at the Norwood office by Telex: , TWX: 710/ , or cable: ANALOG NORWOODMASS. You may get more information on Analog Devices products from the following sources: Contact your local Analog Devices sales representative or authorized distributor. Access the Analog Devices internet home page at: Access the Computer Products Divsion s Bulletin Board Service (BBS) at speeds up to 14,400 baud, no parity, 8 bits data, 1 stop bit, dialing (617) This BBS supports: V.32bis, error correction (V.42 and MNP classes 2,3, and 4), and data compression (V.42bis and MNP class 5). Access the Computer Products Division s File Transfer Protocol (FTP) at: ftp ftp.analog.com or ftp or from an internet browser ftp://ftp.analog.com/pub/dsp (This site is a mirror of the BBS). 1.5 Warranty Analog Devices warrants G21K for users who have purchased this program as part of an ADSP Family Development Software package according to the terms and conditions of the ADSP-2100 and ADSP Family Development Software License Agreement provided with this software distribution, subject to the GNU General Public License, also provided therein. The UNIX license grants the right to use this product on either Sun or Solaris, but not both. page 2

6 2 SALES PACKAGE This software package is available for PC workstations. The part numbers are: Part Number ADDS-210xx-SW-SUN ADDS-210xx-SW-PC Includes this software... Assembler, Linker, Librarian, Assembly Library, ADSP Simulator, ADSP Emulator, ADSP-2106x Simulator, ADSP-2106x Emulator, PROM Splitter, G21K C Compiler, C Runtime Library, ADSP-2106x Compactor (Beta version), ADSP-2106x Loader Assembler, Linker, Librarian, Assembly Library, ADSP Simulator, ADSP Emulator, ADSP-2106x Simulator, ADSP-2106x Emulator, PROM Splitter, G21K C Compiler, C Runtime Library, ADSP-2106x Compactor (Beta version), ADSP-2106x Loader page 3

7 3 SOFTWARE INSTALLATION Note the requirements for your package and follow the appropriate instructions. 3.1 PC Version The PC package contains a set of 3-1/2" high-density diskettes. Make sure that your disk drive is capable of reading the diskettes PC Requirements Microsoft Windows 3.1 or higher is required to run Windows-based tools. Because these tools have not been validated on either Windows 95 or Windows NT, we do not support their use on either of these systems. These tools may run on Windows 95 and Windows NT, but some errors can occur that are non-recoverable. This software requires up to13 MB of hard disk storage. The required system configuration to run the development software is a 386, or higher, based PC with hard disk, high-density floppy disk drive, a color video card and VGA monitor, and a minimum of 2 MB extended RAM. DOS 3.1 or higher. A mouse is highly recommended. You must have at least 450 Kb of memory available in the lower 640 Kb in order for the software to run properly. Most device drivers and TSRs consume this lower memory. Maximize the low memory available to the software by moving as many of these device drivers and TSRs into high memory. The software opens many files and accesses these files frequently. Performance can be degraded, or fail in some cases, if DOS is not set up to support this. In the config.sys file, be sure the following directives are present and the values for these directives are at least equal to the minimum shown below: BUFFERS=25 FILES=40 If you will be using the development software in native DOS, both Extended Memory Support (XMS) and Expanded Memory Support (EMS) are required. Use memory managers that support both standards and be sure not to disable EMS memory in your memory manager if you will be running native DOS. If you will not be using the development software in native DOS, but will use the software in DOS boxes under Windows, only XMS memory support is required. If you are running TMS under Windows 3.1 (or 3.11) you will need to edit the DOSPPRMPT.PIF file as follows: 1. Start the PIF Editor. 2. Open the file DOSPRMPT.PIF. This file is normally located in the \WINDOWS directory. 3. Set the memory requirements (KB Desired) to -1 (minus one) for main memory, xms, and ems memory. 4. Save the changes and exit. These changes allow images running in a DOS window to allocate as much real memory as needed and prevent memory allocation errors. page 4

8 DPMI Server needed The 3.3 release requires you to have a DPMI server installed. As such the release will not work with vanilla DOS. An error such as Load error: no DPMI will result if you try and run the release without a DPMI server. You may either obtain a commercial DPMI server (for example, run g21k in a DOS box from windows), or download and install CWSDPMI (v2misc\csdpmi3b.zip from Simtel.Net mirrors) which is a free DPMI server. Windows 3.1 Under Windows, be sure you ve allocated a sufficiently large swap file (at least 40 Mbytes) from the Windows Control Panel and make sure the.pif file for your program doesn t have too low a limit on EMS/XMS usage. You must make sure the size of your Windows swap file can be at least two times the largest virtual memory size you need. Check if you have enough free disk space. If you don t, run a defragger (Windows needs the swap file to be contiguous). This size is normally limited by the virtual=4 times free physical rule, but you can change that by inserting the line: PageOverCommit=n in the [386nh] section of your system.ini file. The parameter n is 4 by default, but can be set to be as large as PC Installation Procedure for Windows 3.1 The software uses a Windows installation utility to load the software onto your hard drive. To install the software: 1. Insert the floppy into your PC. 2. Start Windows if it is not already running. 3. From the Program Manager, File Manager or the Start Menu in Windows 95, select Run... from the File menu. 4. In the dialog box that appears, type the following 5. a:\install (or b:\install ) 6. Follow the directions on the screen. 7. Reboot your PC after completing the installation for all changes to take effect. The installation procedure installs the simulator and emulator initialization and help files into the c:\adi_dsp directory. Copy these files to the c:\windows directory before attempting to run the simulator or emulator. This ensures proper functioning of these programs PC Environment Variables The development software requires several environment variables in order to run properly and efficiently. Because the installation procedure is Windows based, these environment variables must be set manually. This section describes what these environment variables are used for and how to change them. In addition to these environment variables, remember to include the development tools executable directory in your search path. All environment variables are typically setup in your autoexec.bat file. See the Readme.txt file on the installation disk, and your installation directory, for more information. Variable Name Typical Value Description ADI_DSP C:\ADI_DSP Points to the root directory of the development tools software. Insure there is no trailing white space after the pathname. TMP C:\TMP Points to a directory that all tools, except the compiler, will use for temporary file storage. For optimum performance from the tools, this should point to a sufficiently large RAM drive. page 5

9 3.2 Sun Version The Sun package contains a CD-ROM Sun Requirements The following is required for Sun Installations: System SUN-4, SPARC -based Operating System SunOS or SunOS (Solaris) X Server X11R5 or OpenWindows 3.0 Window Manager mwm (Motif 1.2), olwm or twm Disk Drive 22 MB plus 48M swap space Tape Drive CD-ROM Drive RAM 12 MB Miscellaneous Color monitor highly recommended, keyboard and mouse required. In addition, the development software, specifically the simulators, use the gnuplot graphics package for the Free Software Foundation for plotting memory. If you plan on using the plotting feature of the simulators, be sure you have versions 3.5 of gnuplot in your executable search path. You can obtain gnuplot from the official distribution site; ftp.darmouth.edu [ ]. The file is called /pub/gnuplot/gnuplot3.5.tar.z. Official mirror sites, in Australia, monu1.cc.monash.edu.au [ ] and in Europe, irisa.irisa.fr [ ]. If you are using the Xnews server, be sure Xnews patch # is installed. This patch can be obtained from Sun, via anonymous FTP, at sunsolve.sun.com. The file is called /pub/patches/ tar.z Sun Installation Procedure The software uses an installation utility to load the software, from the CD-ROM, onto your hard drive. To install the software: 1. Insert the CD-ROM into the drive. 2. Create a directory where the software will be installed, typically named adi_dsp. 3. Use the cd command to make this the default directory. 4. Extract the software from the CD-ROM with the following command: tar -xvf cd_mount_point'/sunos.tar or tar -xvf cd_mount_point'/solaris.tar 5. Move the windows directory created in the adi_dsp subdirectory to your home directory. This can be done by entering the following at the command line: mv full pathname of the adi_dsp directory /windows ~/. 6. Create the ADI_DSP environment variable and add the executable directory to your default path. This is typically done in your.cshrc file by adding the lines: setenv ADI_DSP full pathname of the adi_dsp directory set path = $path ($ADI_DSP/bin) setenv MWHOME ${ADI_DSP}/mw source ${MWHOME}/setup-mwuser.csh 7. Source your.cshrc file or, log out and then log back in for the changes to take effect. page 6

10 3.2.3 Sun Environment Variables When you followed the above installation procedure, you created all the environment variables needed by the software. This section describes what these environment variables are used for and how to change them. Variable Name Typical Value Description ADI_DSP adi_dsp Points to the root directory of the development tools software. Insure there is no trailing white space after the pathname. MWHOME adi_dsp/mw Points to the directory that contains the windowing library routines needed to run the simulators. page 7

11 4 CHANGES FROM PREVIOUS RELEASE This section describes the changes from release 3.2 to release 3.3 and The changes include: binary executables are in a different location Assembler, Loader, Linker, Simulator, Emulator, G21K Driver, G21K Preprocessor, G21K Compiler, G21K Run Time Library, and CSWAP have changed. A new tool, the compactor, is available in this release and is documented in Appendix A of this Release Note. These changes are described in detail in this section. 4.1 Binary Executables Directory The binary executables have been moved from C:\ADI_DSP\21k\BIN to C:\ADI_DSP\BIN. You must change all paths and working directories to access these files in this new location. 4.2 Assembler Added new assembly instruction. A new instruction (IDLE16) has been implemented for the The IDLE16 instruction behaves identically to the IDLE instruction, except that during the IDLE16 instruction execution, the internal clocks of the chip runs at 1/16th the frequency while the processor waits for an interrupt. When the IDLE16 instruction is executed, there should be no outstanding external memory operations. The interrupt recognition circuitry will also run at 1/16th the frequency. 4.3 Assembly Run-Time Library None. 4.4 Loader The loader has undergone major changes since the last release. This new documentation is to supersede anything currently in the SHARC User Manual and the Assembler Tools & Simulator manual Introduction The loader is a utility program supplied with the ADSP-2106x Family Development Software. The loader coverts an ADSP-2106x executable program, generated by the linker, into a format which can be used to boot a target hardware system and initialize its memory. The loader s invocation command is ldr21k. The following naming conventions are used throughout this documentation. The loader refers to ldr21k contained in the software release. The boot loader or kernel refers to the executable file that performs the memory initialization on the target. The boot file refers to the output of the loader that contains the boot loader and the formatted system configurations. Booting refers to the process of loading the boot loader, initialization system memory, and starting the application on the target. Memory is referred to as being either data memory, program memory, internal or external memory. The ADSP2106x has a special hardware feature that load a small program into internal memory at chip reset. This program can come from external PROM, the host port, or the link port, based on how the chip s external pins are hooked up. The ADSP-2106x supports three booting modes: EPROM, HOST, and LINK. The SHARC also supports 16-bit, 32-bit, 40-bit and 48-bit data memory. It is designed for use with systems that execute from RAM, internal, page 8

12 external, or both. A boot file generated with EPROM or HOST boot mode and with one input file by the loader can be tested in the ADSP2106x Simulator. Each booting mode packs boot data into 48-bit instructions and uses DMA channel 6 of the ADSP-2106x' on-chip DMA controller to transfer the instructions to internal memory. For EPROM booting via the external port, the ADSP-2106x reads data from an 8-bit external EPROM. For HOST booting, the ADSP-2106x accepts data from a 16/32-bit host microprocessor (or other external device). For LINK booting mode, the ADSP-2106x receives 4-bit wide data in link buffer4. If no boot mode is selected at reset, the ADSP-2106x starts executing instruction from address 0x in external memory. The boot loader usually replaces the mem21k runtime memory initializer. Any executable file to be processed with the ldr21k boot loader should normally not be processed by mem21k. The -nomem switch of the C compiler should be used when compiling any c source files to disable mem21k. When compiling with the -nomem switch, the architecture file s seg_init section need only contain 16 slot/locations of space. The DMAC6 control register is specially initialized for booting in each mode. DMA Channel 6 is configured as external port buffer 0 when used for EPROM and HOST booting, and configured as link port buffer 4 when used for LINK booting mode. In general, the boot process begins by downloading the boot loader onto the target system. The boot loader then sets up the system as necessary, and begins to load initialization data. The boot loader initializes the entire system, with the exception of the area occupied by the loader itself. Once the boot loader has finished initializing the rest of the system, it needs to load over itself. ldr21k can figure out the type of processor in the target and its memory configuration, and the widths of the memory segments from the coff file executable. The loader uses this information to initialize memory correctly. Note that when using any of the power-up booting modes, address 0x20004 should not contain a valid instruction since it is not executed during the booting sequence. A NOP or IDLE instruction should be placed at this location. The loader requires this location for last minute patching of the system state before starting the target executable. The loader generates a warning if does not contain NOP or IDLE. The SYSCON and WAIT registers should be configured with the correct value in the kernel before generating the boot file. During the boot procedure, external memory writes may happen with incorrect values in SYSCON (bank size) and WAIT (wait mode and counts), and the memory access may fail. The kernel source files 060_link.asm, 060_host.asm and 060_prom.asm should be edited to add the appropriate initializations of SYSCON and WAIT if external memory loading is required. If the kernel for EPROM, HOST, and LINK booting modes is customized, be sure that segment named seg_ldr (found in $ADI_DSP\21k\etc\060_ldr.ach) is defined. For JTAG boot on the ADSP-21020, the segment boot_rom is used. page 9

13 4.4.2 Selecting The Booting Mode The booting mode is selected using the LBOOT, EBOOT, and ~BMS pins as shown in Table 1.1. EPROM booting is selected when the EBOOT input is high. This causes ~BMS to become an output, to be used as the boot EPROM chip select. ~BMS is deasserted when ADSP-2106x is not the bus master. When EBOOT is low, ~BMS becomes an input used to select between HOST boot mode or no boot mode. Pin Type Description EBOOT I EPROM Boot Select. When EBOOT is high, The ADSP-2106x is configured for booting from an 8-bit EPROM. When EBOOT is low, the LBOOT and ~BMS inputs determine booting mode. LBOOT I LINK Boot - HOST Boot Select. When LBOOT is high, the ADSP-2106x is configured for link port booting. When LBOOT is low, the ADSP2106x is configured for host processor booting. ~BMS I/O/T* Boot Memory Select. Output: Used as chip select for boot EPROM devices (when EBOOT=1, LBOOT=0). In a multiprocessor system, ~BMS is output by the bus master. Input: When low, indicates that no booting will occur and that ADSP-2106x will begin executing instructions from external memory. *Tristatable only in EPROM boot mode(when ~BMS is an output). EBOOT LBOOT BMS Booting Mode 1 0 output EPROM (connect ~BMS chip select) (input) Host processor (input) Link port (input) No booting. Processor executes from external memory (input) reserved 1 1 x (input) reserved Boot loader 060_prom.asm is the source file for the ADSP-2106x PROM default loader which is loaded into seg_ldr at reset. The architecture file is named 060_ldr.ach. 060_host.asm is the source file for the ADSP-2106x HOST default loader which is loaded into seg_ldr at reset. The architecture file is named 060_ldr.ach. 060_link.asm is the source file for the ADSP-2106x LINK default loader which is loaded into seg_ldr at reset. The architecture file is named 060_ldr.ach. Each kernel begins with defining macros that contain addresses of various IOP registers that are used in the code following by table containing the interrupts vector, up to and including the DMAC6 interrupt. Most of these interrupts are not necessary for the operation of the boot loader. The only interrupts used by the kernel are the reset interrupt (00x x02007) and the DMA6 interrupt (0x x20043). The kernel operates as the following sequence: 1. The External Port DMA Channel 6 interrupt (EP0I) is activated after the DMA transfers stop. DMAC6 control setting is stored in R2 for later restore and DMAC6 is clear for new setting. 2. ~BMS is deactivated and normal external memory select are activated by clearing the BSO bit in SYSCON register. Three copies of SYSCON are used in the program; one that contains the original value of SYSCON, one page 10

14 that contains SYSCON with BSO bit set which allows that ADSP-2106x gains access to the boot EPROM, and a third with the BSO bit cleared. When BSO=1, the EPROM packing mode bits in the DMACx control register are ignored and 8-48 bit packing is forced. (Note that 8 bit packing is only available during EPROM booting or when BSO is set). When one of the external port DMA channels is being used in conjunction with the BSO bit, none of the other three channels may be used. When BSO=1, ~BMS is not asserted by a core processor access, only by a DMA transfer. This allows your bootstrap program (running on the ADSP-2106x core) to perform other external accesses to non-boot memory. 3. Interrupts and nesting are enabled for DMA transfer. The IMASK register is set to allow DMA6 and MODE1 register is set to enable interrupts and allow nesting. 4. Get processor id from SYSTAT register. Find start address of boot section for this processor in the processor idstarting address table (for multiprocessor EPROM mode). The table has 7 48-bit entries formatted as: Address(32 bit) Processor id (16 bit) 5. DMAC6 control register is set to 0x221 and DMAC6 parameters are set up to read data word by word from the starting address of boot section of corresponding processor id in EPROM. Each word is read in to address 0x20004 for dispatching. Each boot section for a specific processor could includes more than one initialization block. Each block is formatted as: Not used (MSB 32 bits) Data type (LSB 16 bits) Address (MSB 32 bits) Length (LSB 16 bit) Boot Data (48 bit) : : 16 LSB of the first word is the data type of each data block. 32 MSB of the second word is the starting address of internal memory and 16 LSB of the second word is the length of following data. Each initialization block is identified by a 16-bit tag which proceeds the block. Each type of initialization has a unique tag number. Tag Number Initialization Type 0 FINAL INIT 1 ZERO DM16 2 ZERO DM32 3 ZERO DM40 4 INIT DM16 5 INIT DM32 6 INIT DM40 7 ZERO PM16 8 ZERO PM32 9 ZERO PM40 10 ZERO PM48 11 INIT PM16 12 INIT PM32 13 INIT PM40 14 INIT PM48 Kernel initializes both internal and external memory by reading the data form EPROM using a routine called read_prom_word and write to specific location of memory. For zero-valued format data block whose tag is one of the 1,2,3,7,8,9,or 10, an initialization of 16 or 32 bit memory is done in a loop which writes a zero-value to memory. Any initialization of 40 or 48-bit PM memory uses a write with the PX register set to zero. For non-zero format data block whose tag one of 4,5,6,11,12,13, or 14 the kernel enters a loop which reads one 48-bit word and page 11

15 writes the appropriate width value to memory. This loop is repeated once for each word being initialized. After kernel reads each value from EPROM, it locks the bus while it writes the value to memory. The bus is unlocked when the write is completed. After the boot loader completes initialization of this block, it reads the next tag and executes the appropriate initialization routine. 6. In the final initialization stage, the kernel loads the first 256 words of target executable file and overwrites itself. The final initialization is indicated by a 0 value tag. When the loader detects this tag, it reads the next 48-bit word. This word indicates the instruction that should be located at 0x20040 when the loading is completing. This instruction is loaded into the 48-bit PX register after the boot loader has finished initializing internal memory. The kernel requires that address 0x contain an RTI instruction because a DMA6 interrupt is generated when the initialization is complete. The R9 register is loaded with 0xbdb0000; this is the encoded instruction PM(0,I8)=PX. The next bit words are loaded into memory over the boot loader. This process is executed with a DMA transfer sequence which, when completed, RTI is executed at address 0x20040, returning to address 0x An instruction at this address sets SYSCON to its initialization value, and writes the correct instruction at address 0x The code then proceeds to address 0x20005 which should be the beginning of user application code. Note that the kernel assumes IMDW is 0 during booting process before it is set to 1 in the final boot stage of the kernel. Also remember that when using any of the power-up booting modes, location 0x20004 should not contain a valid instruction since it is not executed during the booting sequence. A NOP or IDLE instruction should be placed at this location.if kernel is going to initialize external memory, be sure the value set in SYSCON and WAIT register are correct, otherwise the processor may hang. Be aware that the value in DMAC6 is non-zero and that the IMASK is set to allow DMAC6 interrupts. Because the DMAC6 interrupt remains enabled in IMASK, it must be cleared before this DMA channel is used again. Otherwise, unintended interrupts may occur EPROM booting mode EPROM booting mode is selected when the EBOOT input is high and LBOOT is low which causes ~BMS to become an output, to be used as the boot EPROM chip select. The byte-wide boot EPROM must be connected to data bus pin The lowest address pins of the ADSP-2106x should be connected to the EPROM s address lines. The EPROM s chip select should be connected to BMS~ and its output enable should be connected to RD~. During reset, the ADSP-2106x s ACK line is internally pulled high with a 2K Ω equivalent resistor and is held high with an internal keeper latch. It is not necessary to use an external pullup resistor on the ACK line during booting or at any other time. The External Port DMA Channel 6 becomes active following reset; it is initialized to 0x02a1 which allows external port DMA enable and selects DTYPE for instruction words. The packing mode bits PMODE are ignored, and 8-to- 48 bit packing is forced with least-significant-word first. The UBWS and UBWM fields of the wait register are initialized to generate six wait states for the EPROM access in unbanked external memory space. Parameter Register Initialization Value II6 0x IM6 uninitialized (increment by 1 is automatic) C6 0x0100 (256 instruction words) CP6 uninitialized GP6 uninitialized EI6 0x EM6 uninitialized (increment by 1 is automatic) EC6 0x0600 (256 words x 6 bytes/word) Table 1.3 shows how the DMA Channel 6 parameter registers are initialized at rest for EPROM booting. The count (C6) is initialized to 0x0100 for transferring 256 words to internal memory. The external count register (EC6), which is used when external addresses are generated by the DMA controller, is initialized to 0x0600 (i.e. 0x0100 words with six bytes per word). page 12

16 At system start-up, when the ADSP2106x s ~RESET goes inactive, the following sequence occurs: 1: The ADSP-2106x goes into an idle state, identical to that caused by the IDLE instruction. The program counter (PC) is set to address 0x : The DMA parameter registers for channel 6 are initialized (as shown in Table 1.3 above). 3: ~BMS becomes the boot EPROM chip select. 4: 8-bit DMA transfers from EPROM to internal memory begin, on the external port data bus lines : The external address lines (ADDR31-0) start at 0x and increment after each access. 6: The ~RD strobe asserts as in a normal memory access, with six wait states (seven cycles). The EPROM is automatically selected by the BMS~ pin after reset; other memory select pins are disabled. The ADSP-2106x s DMA controller reads the 8-bit EPROM words, packs them into 48-bit instruction words, and transfers them to internal memory until 256 words have been loaded. The DMA external count register decrements after each EPROM transfer. When EC6 reaches zero, the DMA transfer stops and EP0I is activated. RTI return the program counter to 0x20004 where kernel begins. For EPROM booting mode of a single processor with ID=0, the -id#exe switch should not be used and the first executable in the command line will be included in the boot file. For a single processor with ID=1, the -id1exe switch must be used (See the section on Switches 4.4.3) The WAIT register UBWM (used for EPROM booting) is initialized at reset to both internal wait and external acknowledge required. The ACK pin keeper latch initially holds acknowledge high (asserted). If acknowledge is driven low by another device during an EPROM boot, it is possible the keeper latch may latch acknowledge low. The SHARC will view the deasserted (low) acknowledge as a hold off from the EPROM. Wait states will continually be inserted thus preventing the EPROM boot from completing. It is recommended that the WAIT register be changed early within the first 256 word boot kernel so that UBWM is set to internal wait mode (01) HOST booting mode ADSP-2106x accepts data from an 16-bit host microprocessor (or other external device) via the external port EPB0 and pack boot data into 48-bit instructions using channel 6. HOST is selected when the EBOOT and LBOOT inputs are low and BMS~ is high. After reset the ADSP-2106x goes into an idle stage with the program counter set to address 0x ADSP-2106x enters slave mode and wait for the host to download the boot program. The parameter registers for External port DMA Channel 6 are initialized as below: The DMA Channel 6 Control register is initialized to 0x00a1, which allows external port DMA enable and selects DTYPE for instruction words, PMODE for 16-to-48 bit word packing, and least-significant-word first. Because the host processor is accessing the EPB0 external port buffer, the HPM host packing mode bits of the SYSCON register must be set to correspond to the external bus width specified by the PMODE bits of DMAC6 control register. If a different packing mode is desired, the host must write to DMAC6 and SYSCON to change the PMODE and HPM setting. Parameter Register Initialization Value II6 0x IM6 uninitialized (increment by 1 is automatic) C6 0x0100 (256 instruction words) GP6 uninitialized GP6 uninitialized IE6 uninitialized EM6 uninitialized EC6 uninitialized page 13

17 The host boot file created by the loader requires the host processor to perform the following sequence of actions: 1: The host initiates the booting operation by asserting the ADSP-2106x s ~HBR input. This tells the ADSP-2106x that the default 16 bit bus width will be used. The host may also optionally assert the CS~ chip select input to allow asynchronous transfers. 2:After the host receives the HBG~ signal back from the ADSP-2106x, it can start downloading instructions by writing directly to the external port DMA buffer 0 or it can change the reset initialization conditions of the ADSP- 2106x by writing to any of the IOP control registers. The host must use data bus pins : The host can continue to write 16-bit words to EPB0 until the entire program is booted. Between host s each writing to external port DMA buffer 0, 12 cycles is the minimum intervention, i.e. there must be at least 12 cycles between host release bus and next bus request. After 256 instructions have been downloaded, the DMA transfers stop and the following sequence occurs: 1: The External Port DMA Channel 6 interrupt (EP0I) is activated. DMAC6 control setting is stored in R2 for later restore and DMAC6 is clear for new setting. BUSLCK bit in MODE2 to lock out host. 2:SYSCON register value is stored in R12 for restore. 3: Interrupts and nesting are enabled for DMA transfer. The IMASK register is set to allow DMA6 and DMA7 interrupts, and MODE1 register is set to enable interrupts and allow nesting. 4: DMAC6 control register is set to 0x00a1, and DMAC6 parameters are set up to read the data word by word from external buffer 0. Each word is read in to address 0x20004 for dispatching. The data through this buffer has structure of boot section which could include more than one initialization block. BUSLCK bit in MODE2 is cleared to let host write in the external buffer 0 right after the DMA Channel 6 is activated. For the data structure of boot section and initialization please refer loader section in PROM booting. 5: In the final initialization stage, the kernel loads the first 256 words of target executable file and then overwrites itself. The final initialization works the same way as that of EPROM booting except that BUSLCK bit in MODE2 register is cleared to allow host to write to the external port buffer. Note that kernel assumes IMDW is 0 during booting process except for the final initialization stage. Also remember that when using any of the power-up booting modes, location 0x20004 should not contain a valid instruction since it is not executed during the booting sequence. A NOP or IDLE instruction should be placed at this location. If kernel is going to initialize external memory, be sure the value set in SYSCON and WAIT register are correct, otherwise the processor may hang. Be aware that the value in DMAC6 is non-zero and that the IMASK is set to allow DMAC6 interrupts. Because the DMAC6 interrupt remains enabled in IMASK it must be cleared before the DMA channel can be used again. Otherwise, unintended interrupts may occur LINK booting mode ADSP-2106x receives data from an 4-bit link buffer 4 and packs boot data into 48-bit instructions using channel 6. LINK mode is selected when the EBOOT is low and both LBOOT and BMS~ are high. The external device must provide a clock signal to the link port assigned to link buffer 4. The clock can be any frequency, up to a maximum of the ADSP-2106x clock frequency. The clock s falling edges strobe the data into the link port. The most significant 4- bit nibble of the 48-bit instruction must be downloaded first. The link port acknowledge signal generated by the ADSP-2106x can be ignored during booting since the link port cannot be preempted by another DMA channel. The LINK port booting operation is similar to the HOST booting operation; the II6 and C6 parameter registers for DMA Channel 6 are initialized to the same values. The DMA Channel 6 Control Register initialized to 0x000a0. The LCTL and LCOM link port control registers are overridden during LINK port booting to allow link buffer 4 to receive 48-bit data. Be aware that after booting completes, the IMASK remains set to allow DMAC6 interrupts. It must be cleared before link buffer 4 is enabled, otherwise unintended link interrupts may occur. page 14

18 Multiprocessor Prom Booting All ADSP-2106xs Boot in turn from a single EPROM. The BMS~ signals from each ADSP-2106x may be wire-or ed together to drive the chip select pin of the EPROM. Each ADSP-2106x can boot in turn, according to its priority. When the last one has finished booting, it must inform the others that program execution can begin. For multiprocessing EPROM booting, the -id#exe switch is used to specify which executable files are targeted for SHARCs specific SHARC IDs. For EPROM booting mode of a single processor with ID=0, the -id#exe switch should not be used and the first executable in the command line will be included in the boot file. For a single processor with ID=1, the -id1exe switch must be used. Multiple files can only be specified in EPROM booting mode. The WAIT register UBWM (assumed for EPROM booting) is initialized at reset to both internal wait and external acknowledge required. The ACK pin keeper latch initially holds acknowledge high (asserted). If acknowledge is driven low by another device during an EPROM boot, it is possible the keeper latch may latch acknowledge low. The SHARC will view the deasserted (low) acknowledge as a hold off from the EPROM. Wait states will continually be inserted thus preventing the EPROM boot from completing. It is recommended that the WAIT register be changed early within the first 256 word boot kernel so that UBWM is set to internal wait mode (01) Switches ldr21k [infile]/[-id#exe=file.exe ] [-b{type} -c{custom} -f{format} -l file -o file -p{address} -v -h -t{timeout}] Based on the requirements of your system design, you may need to modify the kernel file. If changed are made to the kernel, for example, if the kernel initializes external RAM, it may need to change the wait state configuration in the WAIT register of the external memory and select bank size MSIZE in the SYSCON register. There is a commented section area at the start of each kernel to place such modifications. How to recompile: Kernel for EPROM booting: asm21k -adsp _prom ld21k -a 060_ldr.ach 060_prom Kernel for HOST booting: asm21k -adsp _host ld21k -a 060_ldr.ach 060_ host Kernel for LINK booting: asm21k -adsp _ link ld21k -a 060_ldr.ach 060_ link -id#exe=filename Only for multiprocessor system, # should be the number > 0 and <= 6; -b{type}: Where type indicates the method of booting to be used. The value of type can be prom, host, and link. The default is -bprom. -c{custom} This switch causes the loader to change operation for a custom boot loader file. The value of custom can be or The loader will use this address as the dispatching register during the loading process. Since the default kernel has chosen 0x20004 as the dispatching register slot, this switch should not be used with default kernels. page 15

19 -f(format) Where format describes the output format of the.ldr file. In EPROM booting mode, the value of format can only be hex which is also default value if no format is specified. In HOST and LINK booting mode, value of format can be one of ascii, binary, and include. Default format is ascii. -h Display usage. -l Specify an alternate boot loader for this boot file. If this option is not specified, the loader will use the boot loader in the current directory (if available), or from the ADI_DSP/21k/etc subdirectory. -o Specify output file name. -p(address): Specify EPROM starting address. Only used with EPROM booting mode. Without this switch, boot file is put at the very beginning of EPROM with starting address 0x0 which is SHARC s external address 0x t(timeout) Specify a timeout value. Timeout is in the range from 3 to and default is It limits the number of cycles that the SHARC will spend on initializations of external memory. The value of Timeout is linearly related to the number of cycles that the SHARC will lock the bus during booting. Specifically, the timeout instructs the SHARC to lock the bus for about 2*timeout cycles at most. So, if you have a very fast host that does not like to be locked out, use relatively small value for timeout value. -v Verbose. 4.5 Linker Added new memory configuration support. Accepts new.adsp21061 directive in architecture file. 4.6 Librarian None 4.7 Simulators ADSP Simulator - None. ADSP-2106x Simulator Major simulator changes to last version: 1. Memory change: Support memory layout for processor. 2. Cache: Add cache view function. It is listed under Core Other Cache Contents, which will show cache contents if cache is enabled. Add cache Control register window. It is listed under Core Other Cache Control. 3. Peek: Add a Peek menu to main menu, which include the following two sub-menus. Program name. It is listed under Peek Program name, which will show which architecture file simulator is using, which program simulator is running, what is the target processor. It will help those people who run many programs on different processors frequently. Architecture viewer. It is listed under Peek view Architecture, which will display architecture file. 4. Support IDLE16 instruction, that is, it supports single line assembler and dis-assembler of the instruction for page 16

20 4.8 Emulator 5. Program will disable "IOP Lport Ctrl" and "IOP Lport LSRQ" menu item for Implement AI and AF function under EXECUTION Setup Auto-Interrupt Control and Execution Setup Auto-Flag Control. ADSP Emulator - None. ADSP-2106x Emulator Most of above simulator changes will also apply for the emulator, except those functions related to cache, AI, AF. 4.9 Splitter None C Language Tools G21K Compiler Driver A new assembly-language optimizer, the compactor, has been added. See section Optimization levels have changed from the previous release. The -O2 switch continues to perform full compiler optimizations. The -O3 switch now performs the same optimizations as -O2, but now also invokes the compactor. The -O4 switch performs the optimizations of -O2, invokes the compactor, and then disables checks for negative loop counts (see below). The following table summarizes the new optimization levels: Optimizer Switches Optimization -O Perform some optimization -O2 Perform full optimization, do not invoke the compactor -O3 Perform full optimization, then invoke the compactor -O4 Perform full optimization, invoke the compactor, and disable loop checks In the previous release, the -O3 switch performed full optimizations and also disabled loop checks. In Release 3.3(.1), to get the old -O3 behavior, use -O4 -no-co. One of the optimizations the compiler performs at optimization level -O4 is to disable loop checks, normally performed at runtime, which prevent a counted loop from executing if the count is zero or negative. For example, the following program, if compiled with the -O4 switch, would behave incorrectly whenever n were 0 or negative: for (i = 0; i < n; i++) sum += a[i]; Use of the -O4 switch is only recommended after careful analysis of your program to ensure that all loops are executed at least once. Arbitrary switches can now be passed to several compiler stages by supplying g21k with a switch of the form -Ws,opts, where opts is a comma-separated list of arguments to pass and s indicates which stage (p for C preprocessor, o for compactor, a for assembler, or l for linker). For example, you could use g21k -Wo,-ea,-gs,25 to pass the -ea and -gs 25 switches to the compactor. A new switch, -fno_short_double, has been added. This switch directs the compiler to use the 64 bit double precision IEEE floating point format for values of the C double type. By default, the compiler uses the 32 bit IEEE single precision floating point format for both the float and double types. The ADSP-210xx page 17

21 DSPs can operate more efficiently on 32 bit floating point values than on 64 bit values, so using the -fno_short_double switch will lead to significantly slower floating point operation G21K Preprocessor The preprocessor symbol 2106x is predefined for all 2106x processors, in addition to a processorspecific symbol (such as ADSP21060 or ADSP21062 ). The FILE macro now handles backslashes in filenames better on the PC G21K Optimizing C Compiler A problem that caused incorrect code to be generated for some switch statements at -O2 has been fixed. The code generated for bitfield shifts is now correct for shift counts greater than 5. The compiler will no longer generate code in which a jump or branch can occur in the last three slots of a loop without padding it with no-ops. Problems with the generated code for the 64-bit floating point operations compare-to-zero and absolute value (available as the fabs() builtin) have been fixed. A potential code generation problem related to subtraction has been fixed. (While this was potentially a problem, no bad code has been reported or discovered to date.) The compiler will now generate code that avoids a hardware anomaly in pre-version 2.0 silicon for the SHARC. In the anomaly, the pre-modify address will be computed incorrectly if the result of the pre-modify references memory that is off-chip. The compiler is more conservative in its use of the pre-modify addressing mode to avoid this anomaly. For revision 1.2 of the 21060, code sequences of the form if cond move move don't work. The new -mjdwrite switch will cause the compiler not to generate such sequences. A problem in which function prologue and epilogue would still save and restore registers declared as reserved using the -mreserved switch has been fixed. The compiler previously didn't reserve registers when the architecture file reserved registers with the.register/reserved directive. This problem is fixed in this release. The compiler now correctly processes requests to reserve registers which are identified with two-digit numbers (e.g. R14). A problem with pointer arithmetic that could cause the compiler to crash has been fixed. The following example program will now compile successfully: void f( int dm *p) { *p-- = 0; } void g( int pm *p) { int i = -1; *(p-i) = 0; g((void *)0); *(p+i) = 0; } A reported compiler crash related to register allocation has been fixed. The debug directives for longs generated by the previous compiler could cause the debugger to crash. The compiler now generates debug information that does not cause this problem. page 18

22 In previous releases of the PC-hosted SHARC compiler, the compile-time calculations for floating point values were slightly inaccurate. These differences have been fixed in this release. The PC-hosted compiler can now compile much larger programs than in earlier versions. The PC-hosted compiler and SPARC-hosted compiler now generate the same calling sequence in all cases. The compiler now generates more efficient code for comparing PM or DM values to zero. A second scheduler phase is now run to do further optimization. Max and min instructions are now generated for floating point numbers. Previous releases only generated max and min instructions for integer operations. A new optimization that has been added to recognize and reduce the code for a floating point dot product. The resulting code is pipelined for maximum efficiency on the SHARC. The order in which registers are allocated has been enhanced to better take advantage of the SHARC architecture. A problem with optimization of 64 bit double precision values has been eliminated. The problem only could happen at high optimization levels when passing arguments that were 64 bit doubles. When compiling code in which a loop-related variable was compared against zero, and the variable was also used in an expression of the form -variable or expr >> variable, the previous release of the compiler could sometimes generate the compare backwards G21K Run Time Library The TRUNC preprocessor macro defined in def21060.h conflicted with the processor instruction of the same name. The preprocessor macro (a mask for the truncation mode bit in the MODE1 register) has been renamed to TRUNCATE. Several macros in dma.h were incorrect and have been fixed. The macros in dspc.h now use typeof instead of typeof to avoid problems with the -ansi switch. In stdlib.h, RAND_MAX was changed to to reflect the actual range of values produced by rand(). The routines used by the compiler for the signed modulo and unsigned divide operators could previously produce inaccurate results for several reasons. These problems have been fixed. A problem in the routine used to convert doubles to unsigned integers has been fixed. Previously, a single instruction immediately following such a conversion would be executed using truncating 40-bit arithmetic, because the machine mode restore at the end of the routine had a delayed effect. The following functions now work or work better with double-precision values: exp() (used to cause a FLTII trap for large values) fabs() rsqrt() sqrt() The following functions used to produce incorrect results for some ranges of input values. These problems have been fixed. cabsf() div() and ldiv() (failed when numerator < denominator ) fmodf() (previously, could fail on negative numbers) frexp() modff() pow() and powf() (failed for negative base with integer exponent) rsqrt() tan() (failed for negative inputs) page 19

23 atoi() and atol() now return the correct value when passed an empty string. In previous releases they would return random values. The function strtod() now works correctly for more inputs. There is a new function strtodf() which returns a 32-bit value; strtod() always returns a 64-bit value. The compiler now accepts without error calls to strtod() with all legal parameter types. The functions strcpy() and strcat() now work. In previous releases the terminating NUL was not copied. The function strcmppd() is now correct. In the previous release there was an illegal jump in the implementation. strncat(a,b,0) randomly writes into string a. The runtime function histogram() has been fixed. It used to miscount some entries by 1. The zero_cross() functions now work correctly. The iir() function has been corrected. Previously, only the result produced by the first iteration was correct. The runtime function freep() is now part of the library. In previous releases the following code sequence would result in a link failure because _freep was not found: int PM *p=0; free (p); The macros LEFTZ and LEFT0 have been corrected. The routines setjmp() and longjmp() have been corrected and improved. They now correctly save all of the state that the compiler expects and are protected from interrupts. In addition, they have been made smaller and faster. The clear_interrupt() function has been fixed. In previous releases it was possible for the SHARC to miss interrupts that are not being cleared. In the previous release, signal() and interrupt() didn t clear the correct bits in the IRPTL (interrupt latch register) before enabling global interrupts. System integrity could therefore be compromised since interrupts could happen during execution of critical code. These routines have been fixed. Several problems were fixed in the interrupt dispatcher relating to saving scratch registers, popping them from run time stack in correct order, correct manipulations with the MODE1 register, and instruction latency issues. More registers have been saved to better support nested interrupts. Registers I13 and I15 are now saved and restored around interrupt service routines, so that they can be used in scratch registers in the routines. The standard library function atof() now returns a 32-bit float; atoff()is the 64 bit version. The bsearch() function now works. Also, qsort() has been added since the last release Compactor Note: The Compactor is only available for release with the full set of software of release 3.3 and on. The Compactor is not included with the EZ-KIT Lite software package. The compactor (also called GCO, the global code optimizer) is new in this release. The compactor takes assembly code, either compiler-generated or hand-written, and performs SHARC-specific optimizations. By taking advantage of multifunction instructions, pipelining, and various architecture nuances, the compactor is able to tailor the code to run faster. The compactor can be enabled by passing the -CO switch to the g21k driver when compiling a file (either C or assembly). The compactor is also enabled by default at optimization levels -O3 and higher. (Note that -O3 no page 20

24 longer includes optimizations performed at -O3 in previous releases, but is now equivalent to -O2 -CO. See for additional information on optimization changes.) For more information on using the compactor, see Appendix A of this Release Note COFF Tools CSWAP Fixed bug in which bitfields were not being handled correctly CDUMP None. page 21

25 5 RESTRICTIONS This section details restrictions in this version of the ADSP Family Development Software. The restrictions described in this section are supplemental to those described in the corresponding user s manual. 5.1 Assembler When using the backslash (\) line continuation character, do not put any characters after the backslash on the same line; it must be followed immediately by a carriage return. Otherwise, an assembler error occurs. For example, a comment or a space after a backslash causes an assembler error. When using the Rn=FDEP Rx BY <bit6>:<len6> instruction, use only positive numbers for <bit6>. A negative number for <bit6> results in a syntax error that is not properly reported. When multiple instructions are placed on a single line in the source file, the listing file shows only the last instruction on the line. Unprintable special characters in the source file may cause the assembler to crash. Macro substitutions made with a #define statement cannot begin with a number. The following example will fail: #define 2me r0 = 1 In the architecture file, the END value, must be greater than the BEGIN value when defining a segment. If not, when computing the size of a segment, the assembler incorrectly interprets the resulting negative number as a large positive number. In the include directory, there is a file called asm_sprt.h, in which are defined various macros to aid the user in writing assembly level implementations of C functions. The use of this file is described in the C Tools Manual. Omitted from the manual is a statement indicating this file is to be used only as an include file in C programs. Unfortunately, when the file is included from an assembly level routine, the pre-processor defines that are automatically generated by the compiler, are not asserted. As such, what gets included from the file are ADSP-2106x definitions, which is fine if that is your target processor. If your target processor is an ADSP , you must manually define the processor define, ADSP21020, in order to include the proper ADSP definitions. 5.2 Assembly Run-Time Library None. 5.3 Linker The -s switch, used to strip symbolic information from an executable file does not work reliably. The -r switch is no longer supported. The linker will generate an error if the architecture file defines a multiprocessor memory space segment for processor 1, ID = 001, that defines locations 0x80000 through 0x9ffff. This is because that memory space is in fact locations 0x00000 through 0x7ffff of that processor. In the architecture file, the END value, must be greater than the BEGIN value when defining a segment. If not, when computing the size of a segment, the linker incorrectly interprets the resulting negative number as a large positive number. page 22

26 5.4 Loader The boot loader does not make special provision for an executable that can be loaded by the automatic hardware boot alone. It creates a boot file that contains the boot loader, just to load over itself. Although this works without a problem, it generates a boot loader file that is significantly larger (more than twice the size) than necessary. The Loader does not efficiently pack the final initialization. Regardless of the size of the last initialization, the loader places bit words in the boot file. When using the loader, do not use the mem21k utility. Any executable that is going to be processed by ldr21k should not be processed with mem21k. See the -nomem compiler switch. If mem21k is used with the loader, redundant initialization will occur and unnecessary internal memory is used up. The loader requires the use of address 0x20004 for booting an ADSP-2106x target. Any executable file that is going to be processed by ldr21k, should have a NOP or an IDLE instruction at address 0x This only applies to ADSP-2106x targets. As noted in the users manual, the DMAC6 control register will not contain a zero when the program begins execution. The -fbinary switch has not been fully tested and, although implemented, is not supported for this release. 5.5 Librarian None. 5.6 Simulators PC Version The source file sizes in CBUG are restricted to less than 64Kb Restrictions The following pulldown menus are not implemented for this release: Save Layout Execute Instruction Counting Breakpoints Auto-Interrupt Auto-Flag Backtrace The ADSP-2106x silicon prioritizes DMA channels as follows: 0, 1, 2, 3, ChainLoad, ExtRW, 4, 5, 6, 7, 8, 9. The simulator has reversed the priority of ChainLoad and ExtRW. When entering instructions into a PM window, if... else instructions must be entered with a comma (,) before the else. page The simulator allows writing to the following read-only and reserved bits in the IOP memory space: LSRQ: and STCTLx: LCTL: LCOM: 31-26, 25-23, 11-0 LAR: SYSCON: 7 STKY:

27 The simulator incorrectly initializes the multiprocessing vector interrupt register, VIRPT, to 0x40014 (external). The correct value should be 0x20014 (internal). The simulator s display for the bus timeout counter, BCNT, incorrectly displays the bus timeout maximum value, BMAX. The simulator does not automatically clear it s symbol table when a new executable is loaded. The simulator does not honor the short word sign extend bit, SSE, of the MODE1 register. Variable names which are identical to the segment name in which they reside cause the simulator to omit the variable name from the symbol table. The practice of naming symbols and segments with identical names should be avoided. The architecture file.bank directive has no affect. The various.bank qualifiers are not asserted by the simulator. In addition, wait states MSIZE, IMDWx bits etc., are not set automatically. These bits should be set by the user s code at run time. The ADSP-2106x simulator does not support link ports. SPORT DMA transfers are supported. Because the external port master mode DMA transfers with external memory functionality has not been thoroughly tested, it is not a supported feature at this time. Host and PROM booting options are the only boot loading operation that the ADSP-2106x simulator supports. Host boot files must be in ASCII format as created by the loader, ldr21k, with the -fascii switch. Arithmetic loops (i.e. non-counter-based loops) containing one or two instructions that terminate on the first iteration of the loop are not properly simulated. Workaround: Insert NOP instructions into the body of the loop to make it at least 3 instructions long. When enabling or disabling the timer through the MODE2 register, the timer may exhibit an extra cycle of latency before the change takes effect. This extra cycle of latency may also occur when the Auto-Interrupt Control and Auto-Flag Control functions are used. If an assembly label coincides with other labels, only the last label linked will be seen by the simulator symbols display and search. In the DAGs, when setting the base registers via the user interface, the corresponding index register gets set also. This operation differs from the emulators where the index register does not get set. The simulator does not support both serial ports running in loopback simultaneously. The simulator does support loopback of either serial port, provided only 1 serial port is in loopback at a time. DMA SPORT transfers do not halt properly in the simulator. When a DMA count register decrements to zero, and no DMA chaining is called for, the DMA channel should disable itself. However, the DMA activity bit, in the DMASTAT register, is not cleared and the SPORT buffer status bits are incorrect. The Memory Dump command only supports hexadecimal syntax. If dumps in floating point format are required, use the plot memory command, and examine the resulting.plt file. In the ADSP-2106x simulator, if the multiplier underflow bit, MUS, of the STKY register is set, the simulator incorrectly clears the floating point underflow bit, FLTUI, of the IRPTL register when the FLTUI interrupt is serviced. In the status stack windows, the simulator allows the user to modify the FLAG bits, bits 19 through 22, of the ASTAT registers. These simulator should not allow modification of these bits. In the ADSP simulator, Program Memory windows do not support the floating point display mode. In the ADSP simulator, the BSET instruction will not simulate properly if the bit that is to be set lies in bit position 15 through 31. Note the following run-time library functions may not simulate properly as they employ use of this function; A-Law/ U-Law encoding, sin, atof, strtod, dtoi, dmult, dadd and dsub. In the ADSP-2106x simulator, memory references to reserved locations in IO space will result in the Error --- Instruction Timed Out message. page 24

28 The simulator does not support 40 bit fixed point values with the LOAD command; fixed point values are limited to 32 bits. After a chip reset, all simulators, include the 2 clock cycles that are used to fill the fetch/decode/execute pipeline, in their cycle counters. The EZ-ICEs do not count these 2 cycles. Note: This problem exists in the UNIX version only. The simulators (wsim06x and wsim020) hang if you invoke Help more than once during a session. If you invoke Help, exit Help, and invoke Help again, the simulator hangs. This hang-up occurs whether you invoke Help through the Help Menu choices (Contents, Context, or Using Help), through the F1 key, or some combination. To work around this problem, invoke Help once, save Help for later access by using the minimize function, and restore the minimized help as needed during the session. You can minimize Help from the Title Bar by selecting Minimize from the pull-down menu, or by clicking on the Down Arrow in the Windows Emulation or the Button in the Motif window. Certain conditions exist where an illegal memory segmentation definition in an architecture file may not be flagged as an error or warning by the linker, simulator or emulator. If a segment of memory is defined in short word space and again in normal word space, a segment overlap error may not be given even though two segments overlap. If finer granularity memory segmentation, as described in the top part of Figure 5.13 of the SHARC User's Manual, and 32 bit and 48 bit defined segments overlap, the tools may not detect the error. Symptoms which may indicate such an error are runtime errors of "incorrect data in memory; code does not appear to be correct" and "untranslatable op code." When loading a file, the simulator sometimes fails to load very large executables (400k to 500k in size), resulting in a crash. The problem occurs because the executables contain an individual component that is larger than 64k. This problem exists in the simulator, emulator, and EZ-Kit only in the PC version of this release. You can get a patch that fixes this problem in the simulator, emulator, and EZ-Kit by contacting Analog Devices Technical Support. 5.7 Emulator This section describes the restrictions for each ADSP-210xx EZ-ICE emulator Restrictions This section describes restrictions that are common to all ADSP-210xx EZ-ICE emulators. The following pulldown menus are not implemented for this release: Save Layout Execute Instruction Counting Breakpoints Backtrace The Program Manager icons for the emulators are not included. The emulator does not automatically clear it s symbol table when a new executable is loaded. The source file sizes in CBUG are restricted to less than 64Kb. The architecture file.bank directive has no affect. The various.bank qualifiers are not asserted by the emulator. In addition, wait states MSIZE, IMDWx bits etc., are not set automatically. These bits should be set by the user s code at run time. Variable names which are identical to the segment name in which they reside cause the emulator to omit the variable name from the symbol table. The practice of naming symbols and segments with identical names should be avoided. The Memory Dump command only supports hexadecimal syntax. If dumps in floating point format are required, use the plot memory command, and examine the resulting.plt file. page 25

29 In the DAGs, when setting the base registers via the user interface, the corresponding index register does not get set. This operation differs from the simulator where the corresponding index register s value is set when the base register is set. Software breakpoints can not be placed anywhere that a CALL instruction would be invalid (i.e., either of the two instructions following a Delayed Branch jump or call, or last three instructions of a DO loop). When loading an executable with Memory Verify ON, any ports that are defined may report a readback error. Ignore this or turn Memory Verify OFF. PM locations, 0 through 7 for ADSP and 0x20000 through 0x20003 for ADSP-2106x, must not contain any user code and should be set to 0 (NOP). Interrupts to the are not latched when the emulator is halted. Single-step does not wait on IDLE instructions (i.e., executes as a NOP). IRPTL and IMASKP have bit 0 set while stepping. Timer continues to operate while software breakpoints are encountered (for approximately 4 cycles with zero wait states). If the timer interrupt gets serviced while a software breakpoint is executed, the status stack may not get cleaned up properly; there may be an extra MODE1/ASTAT pair on the stack. PMDA instructions perform both program memory accesses when single-stepping (for example, if the cache contains the instruction to be fetched, it may fetch the instruction anyway). Software breakpoints remain in memory if you select the RUN command then EXIT or QUIT. This results in the opcode at the breakpoint address being lost (breakpoint address will contain a CALL). When entering instructions into a PM window, if... else instructions must be entered with a comma (,) before the else. Do not set the IMASKP bit 0 (EMUI). This causes the processor to enter emulator space. The [user_sect] base_address variable in the wice0x0.ini file must be set correctly according to the actual jumper configuration on the emulator PC plug-in board. The default address for the board is 0x340. See the EZ-ICE Emulator Manual for complete hardware installation details. FADDR and DADDR always display the current PC value in the Program Counters window. After a chip reset, all simulators, include the 2 clock cycles that are used to fill the fetch/decode/execute pipeline, in their cycle counters. The EZ-ICEs do not count these 2 cycles. When loading a file, the emulator sometimes fails to load very large executables (400k to 500k in size), resulting in a crash. The problem occurs because the executables contain an individual component that is larger than 64k. This problem exists in the emulator, simulator, and EZ-Kit only in the PC version of this release. You can get a patch that fixes this problem in the simulator, emulator, and EZ-Kit by contacting Analog Devices Technical Support ADSP-21010/ADSP EZ-ICE Specific Restrictions This section describes restrictions that are common to all ADSP-21010/ADSP EZ-ICE emulators. Stepping over, or setting breakpoints on, the push loop instruction, or the two instructions following a push loop instruction, can cause unpredictable results. When any of the ADSP stacks (PC, status, loop) overflow, the ADSP must be reset to use those stacks. The stack contents displayed after an overflow are all bits set for the PC stack and all bits cleared for Loop and Status stacks. When the target is not running, and the target asserts BR, the ADSP asserts BG. None of the address or control pins are 3-stated as expected, however. page 26

30 Read-only registers (i.e., FADDR, DADDR, PMADR, DMADR, etc.) cannot be set from the user interface. PMI hardware breakpoint placed on the instruction immediately following a program memory data access is ignored until the instruction is cached. Workaround: Use a software breakpoint. The cache is loaded in a different, but valid, sequence. This does not cause the execution sequence to be different. Software breakpoints should not be placed on an instruction immediately following an instruction that unmasks a pending interrupt. Program Memory windows do not support the floating point display mode SHARC Software EZ-ICE Specific Restrictions DMA transfers which are halted by the emulator (see [dma_stop] variable in wice060.ini) are not resumed correctly. The EZ-ICE currently uses the PM bus instead of the DM bus to access external memory for both executable download and for the memory view window. Since the PM bus address is only 24 bits wide, any access to an address above 24 bits will wrap back down to lower memory in a module 2 24 manner. If, upon startup, the architecture file listed in the initialization file contains a.processor statement that conflicts with the target processor, the error message displayed does not include the filename of the architecture file. For example, the error message displayed is Invalid.PROCESSOR directive in. rather than Invalid.PROCESSOR directive in c:\21k.ach. When using the command_timeout feature to automatically stop the emulator after n milliseconds, there is a slight chance that the emulator will halt and then automatically restart. This can happen if the emulator encounters a breakpoint at the same instant as the n milliseconds timer expires. When using the EZ-ICE with the EZ-LAB board and DspHost software library, resetting the 2106x, while the library is in the middle of a PC to EZ-LAB data transfer may cause the PC to hang. The EZ-ICE does not save and restore the instruction cache contents during emulator halts/runs and single steps. As a result, when benchmarking code, run the code under test from start to finish with no breakpoints, halts or single steps SHARC Hardware EZ-ICE Specific Restrictions The input clock rate of the ADSP-2106x target must be >= 20 MHz. The current released version of the EZ-ICE Probe has a problem with signal crosstalk, and can cause severe disruptions with the EZ-ICE. The CLKIN signal coming from the Target (Pin 4 of the Targets 14 pin header) through the 10 inch cable to the EZ-ICE Probe can cross couple significant noise to the other JTAG signals on the 10 inch cable (TMS, TRST~ TCLK, TDO, EMU~, and TDI). This noise crosstalk can cause a failure of the EZ-ICE. If you have a board with this 10 inch cable (not all boards shipped contain it), there are three different workarounds for this problem: 1. Remove the CLKIN pin (Pin 4) from the 14 pin header on the target. This will prevent the CLKIN signal from propagating down the 10 inch cable to the Probe assembly, causing noise crosstalk problems and possibly causing EZ-ICE failures. Note: CLKIN is used for Synchronous Multiprocessor applications, and is not currently enabled in Software. 2. Remove the 10 inch cable completely from the Probe assembly, and replace it with a 14 pin female IDC header that can be soldered to the Probe assembly. Make sure you place an obstruction in pin 3 of the female IDC header you soldered on, this is the key pin for the 14 pin header assembly on the page 27

31 5.8 Splitter None. Target. This will prevent the CLKIN signal from propagating onto the Probe assembly, causing noise crosstalk problems and possibly causing EZ-ICE failures. Note: CLKIN is used for Synchronous Multiprocessor applications, and is not currently enabled in the EZ-ICE Software. 3. Replace pins 3 and 4 of the 10 inch ribbon cable with a 75 ohm small diameter coaxial cable. Solder the center conductor of the coaxial cable with pin 4 at each end of the ribbon cable headers. Solder the shield conductor of the coaxial cable with pin 1 at each end of the ribbon cable headers. This will prevent the CLKIN signal from causing noise crosstalk problems and possibly causing EZ-ICE failures. This workaround will allow synchronous operation when it is implemented in future software releases of EZ-ICE software. Note: CLKIN is used for Synchronous Multiprocessor applications, and is not currently enabled in the EZ-ICE Software. A new 10-inch cable assembly is being developed for the EZ-ICE probe. You can contact Analog Devices Technical Support for the status of this cable. 5.9 C Language Tools G21K Driver The driver operates in a very restricted memory space, and so can only compile a limited number of files at once. If you get an out of memory message, try splitting the command up into multiple invocations of g21k. Note: This restriction exists only in the PC version of this release G21K Preprocessor None G21K Optimizing C Compiler Support for the -mpcrel switch is incomplete. Some PC-relative code is generated, but not for all constructs. ADSP-2106x early silicon does not correctly address memory using pre-modify addressing when the modify register changes the access from internal to external memory or vice versa. Although the compiler has been improved to work around this problem, certain code sequences may still cause problems. Enumeration types with values between 2 31 and (inclusive) are represented using 64 bits even if all values of the type can be respresented in 32 bits. The compiler fails with an internal error when inlining functions which manipulate and dereference pointers. This failure happens when either the inline keyword or the -finline-functions switch is used. The only workaround for this problem is to disable inlining by removing references to the inline keyword and by not using the -finline-functions switch. If you use the inline keyword in your program, you can disable it by adding -Dinline= -D inline = to the g21k command line. When 64 bit integer and enumeration values are converted to 32-bit types, the result is incorrect. NOTE: This restriction exists in the UNIX versions of the released software only; the PC release works as expected. Wide string literals are not handled properly by the compiler. Certain compile time evaluations yield incorrect results. NOTE: This restriction exists in the UNIX versions of the released software only; the PC release works as expected. page 28

32 5.9.4 G21K Run Time Library To use the math functions, you must include math.h. The compiler s built-in square root function does not check for large numbers; this could cause incorrect results. When sqrtf() input exceeds FLT_MAX/2 (1.7e38) and the -O2 switch is used, a negative value may be returned. Use the -fno-builtin switch to avoid this. When polymorphic functions (functions that use pm pointers) are used, and the function returns a pointer to program memory, cast the output of the function to pm. For example: (char pm *). Many standard C I/O routines are still missing. Some operations on 64-bit floating point values may not produce very accurate results The following functions are known to have problems: lib_dmult() (double precision multiply) memmove() fails with PM and DM operands. matinv() is no longer supported. min() and max() are missing. sinh(), cosh(), and tanh() sqrt() is not very accurate for double precision values ffts() Compactor localeconv() strtod() (for 64 bit values) The compactor cannot distinguish between inefficient code and code that looks inefficient but actually has a purpose. For example, if you have ports defined in your system, you may have consecutive reads/writes in your assembly code that look like the following: R0 = DM (I4, M4); R0 = DM (I4, M4); The compactor will see this as an inefficiency problem and eliminate one of the lines. To disable the compactor for specific pieces of code, see section A of this document COFF Tools CSWAP None CDUMP None. page 29

33 APPENDIX A: ADSP-2106X COMPACTOR REFERENCE MANUAL A.1 General Information A.1.1 Introduction The SHARC global code optimizer, gco, also known as the compactor, is an assembly-language optimizer specifically designed to optimize SHARC code by taking full advantage of the options and features provided by the SHARC microprocessor. Gco takes as input SHARC assembly code, either produced by a compiler or hand-written. It rearranges the code, performing a variety of optimizations including compacting multiple instructions into single multifunction instructions, unrolling loops, vectorizing code, and reassigning registers. It produces as output new SHARC assembly code with the same semantics as the input code. Gco is fully integrated into the g21k compiler driver, and requires no extra effort to use. Simply use the -CO switch to g21k or specify optimization level -O3 to enable the additional optimization. A.1.2 Optimizations Performed The following is a description of the optimization techniques performed by gco. Static optimization: Static optimization includes dead-code elimination, copy propagation, code compression and simplification, common subexpression elimination, and substitution using algebraic identities. Memory optimization: Memory optimization performs static and dynamic memory aliasing and attempts to resolve dependencies caused by memory accesses. Loop unrolling: Loop unrolling duplicates the body of a loop specified number of times, which can result in code which has more opportunities for further optimization than the original. Vectorization: Vectorization overlaps the epilog code execution for a given loop iteration with the execution of prolog code for the next loop iteration. Instruction-Level Parallelization: Instruction-level parallelization attempts to rearrange operations to take advantage of the SHARC s multifunction instructions, so that more than one operation can be executed in each cycle. Art substitution: Art substitution replaces parts of the code with logically equivalent code sequences. By default gco will perform most of the optimizations that are available. Individual optimizations can also be enabled or disabled as desired. A.1.3 Basic Blocks A basic block is a sequence of SHARC non-branching instructions in which flow of control enters only at the top. gco assumes that any sequence of instructions bounded at the top and bottom by labels and/or branch instructions is a basic block. page 30

34 A.1.4 Calling Conventions gco assumes the standard ADSP-2106x SHARC programming calling conventions for subroutine calls: registers R0, R1, R2, R4, R8, R12, I4, I12, M4, and M12 are not saved across calls; registers M5 M7 and M13 M15 are fixed value registers. A.1.5 gco Code Optimization Optimization of the code is done as follows: Perform data flow analysis Extract basic block Perform static optimization Build data flow graph Perform art substitution Perform resource reduction Extract patterns for scheduler Perform instruction-level parallelization Second stage optimizations After scanning its input, gco performs comprehensive data flow analysis, calculating resources needed and available for execution of the instructions of the code. It then extracts basic blocks to be optimized. Any basic blocks which are larger than the number of instructions specified by the -gs parameter are broken into chunks of the maximum size, and gco treats each chunk as a basic block. When the basic block is selected the static optimization and art substitutions are performed and dynamic memory map is built. The code generated by the static optimization is used to build the data flow graph. From the data flow graph gco performs resource dependency reduction and then instruction-level parallelization, generating patterns of code that are organized into units of SHARC instructions which take advantage of multifunction instructions wherever possible. If enabled by the -fo parameter, a second stage of optimization is applied. Additional memory optimization and further instruction-level parallelization are performed. page 31

35 A.2 Using the Compiler A.2.1 Invocation Gco is invoked through the g21k compiler driver, by either passing the -CO switch to g21k, or by using optimization level -O3 or higher. Using either switch, gco will be invoked on both C and assembly files given as arguments to g21k. In order to view compactor output, g21k provides a -SO (optimized assembly) switch which causes the compiler to stop after creating a file with a.is extension, containing the optimized assembly code produced by gco. This is analogous to the -S switch which causes the compiler to stop after producing a.s file containing assembly code. A g21k Switches The following is a summary of g21k switches pertaining to the compactor. For more information on the optimization switches, see G21K Compiler Driver. -CO -no-co Compact any C or assembly input files using gco. Do not compact any C or assembly input files. -O2 Optimize code, but do not run gco. -O3 Optimize code, and run gco. This is equivalent to -O2 -CO. -O4 Optimize code, run gco, and disable loop checks. Use this switch with caution. -S Produce an assembly listing (.s file); do not run the assembly preprocessor, the compactor, or the assembler. -SO Produce a preprocessed, optimized assembly listing (.is file); do not run the assembler. With -CO or -O3, the.is file produced contains the output of gco. Without those switches, the file contains the output of the assembly preprocessor; the compactor is not run. -Wo,opts Use the specified compactor options. opts is a comma separated list of arguments. A Compactor Options The following gco parameters can be set using -Wo,opts. -ea -fo Inhibit optimizations which involve applying associative equivalences to floating point arithmetic. The code resulting from such transformations may produce different numerical results than the original code. See A for a more detailed explanation. Enable the second stage (full) optimization, which involves additional memory optimizations and additional multi-instruction analysis. -gs,# Specify the maximum size of a basic block to be processed. The default is 25. -um -lu,# -na -nc Allow for the possibility that the PM and DM memory banks overlap. Normally, gco performs optimizations assuming that the two banks as separate, non-overlapping areas. Specify the number of times loops will be unrolled. The default is 1 (no loop unrolling). Disable art substitution. Disables register allocation. -nd -nm Disable creation of new instructions. Disable memory optimization. page 32

36 A.2.2 Code Options -ns Disable static optimization. -q Quick mode perform optimizations only for basic blocks that are bodies of loops. -slct Optimize only selected areas of code. See A for details. -so Disable all optimizations except static optimization. Only static optimization is performed (unless that too is disabled with -ns). -v Enable vectorization. gco accepts as an input standard SHARC assembly files. All comment lines are ignored except for the optimization directives described in A and A A Selected Code Optimization gco allows you to optimize only selected portions of your assembly code. To do this you must specify the -slct option to gco on the command line (g21k -Wo,-slct), and then enclose the sections of code you wish to have optimized between assembler comment lines as follows:!.start_dco <option list>! (code between these lines will be optimized)!.end_dco!.start_dco <option list> indicates the beginning of the portion of the code that should be selectively optimized. Optimization will stop at the comment line!.end_dco, or, if no such line appears, the remainder of the file will be optimized. <Option list> is an optional list of options to use while optimizing the selected portion of the code; this list, if specified, alters default parameters or parameters specified on the invocation line. Any of the options listed in A.2.1 may be specified in the options list except -slct. The total number of options lists specified in your source code may not exceed 64. To selectively optimize C code in this manner, you can insert the directives into your code using C asm statements. Note these directives are sensitive to capitalization and spacing, and should be used exactly as written above. In particular,!.start_dco (where! is followed by a space) will not be recognized by gco. A Changing Optimization Options gco allows you to change the optimization options in effect in the middle of a file, using the following directive:!.options_dco <option list> <Option list> is a list of options to use while optimizing the following code; the options specified here alter default parameters or parameters specified on the invocation line. Specifying!.options_dco with an empty <option list> will cause the settings to be restored to those at the invocation of gco. Any of the options listed in A.2.1 may be specified in the options list except -slct. The total number of options lists specified in your source code may not exceed 64. This directive is also sensitive to capitalization and spacing, and should be used exactly as written. A.2.3 Suggestions for Using gco This section contains hints and suggestions on using features provided by gco. It should not be considered a comprehensive guide to the usage of gco. As you gain experience using the product, you will develop other techniques which suit your needs and professional habits. page 33

37 A Choosing Command Options In most cases disabling an optimization option will decrease the quality of resulting code. The -fo option does not always improve code that has few memory accesses or few opportunities for multifunction computation. A Basic Block Sizes The setting of the -gs parameter to control the maximum basic block size can have a significant impact on the quality of the code produced by gco. In general, the larger the basic block size, the better the generated code will be. However, large settings for this parameter may significantly increase the memory and/or execution time required to run the compactor. The default basic block size of 25 is an attempt to produce reasonable results without increasing compilation time too greatly. You may see improved results, however, if you increase the maximum size to 50 or higher. Conversely, if the compactor is taking a very long time to execute, try reducing the value of the -gs parameter. A Exact Results When transforming arithmetic expressions, gco always produces code that is mathematically equivalent to the original code. However, due to the inexact nature of floating point calculations, the results produced by optimized code may differ from those produced by the original code. For example, the instructions: f6 = f2 + f4 f6 = f6 + f8 may be replaced by: f6 = f2 + f8 f6 = f4 + f6 which, while mathematically equivalent to the original, may produce a different value in register f6. The -ea parameter will inhibit optimizations which might cause such problems. A Quick Optimization Choosing this options may significantly reduce the execution time of gco without having great impact on the quality of the produced code. A Sample Usage Here are some examples of using the compactor. g21k -O3 -c file.c Compile file.c, optimizing with gco. Creates file.o as a result. This is the normal way to compile C source code using the compactor. g21k -CO -c file.asm Optimize file.asm using gco, and then assemble. Creates file.o as a result. This is the normal way to assemble hand-written assembly source when you want to optimize it using the compactor. g21k -CO -c -Wo,-ea,-gs,50 file.s Optimize file.s using gco, and then assemble. Creates file.o as a result. The compactor will not perform floating point arithmetic transformations, and will use a basic block size of 50. g21k -O3 -S file.c Compile file.c. Creates file.s, containing a listing of (uncompacted) assembly, as a result. page 34

38 g21k -O3 -SO file.c Compile file.c, optimizing with gco. Creates file.is, a listing of optimized assembly code, as a result. One way to examine the effect of the compactor for C source is run both this command and the previous one, and then compare file.s with file.is. g21k -O3 -SO file.s Optimize file.s using gco. Creates file.is, a listing of optimized assembly code, as a result. This is one way to examine the effect of the compactor on a hand-written assembly file. If file.s was produced by the compiler (as with g21k -S), then this can be used as another way to examine the effect of the compactor on C source. g21k -CO -SO file.asm Equivalent to the previous command. This is the normal way to examine the effect of the compactor on an assembly file. g21k -save-temps -O3 -c file.c Compile file.c, optimizing with gco. Creates file.o and a number of intermediate files including file.s and file.is as a result. Running this command and comparing file.s and file.is is yet another way to examine the effect of the compactor on C source. g21k -O3 file1.c file2.c file3.c file4.s file5.asm -lmylib -o myprog Compile file1.c, file2.c, and file3.c, and assemble file4.s and file5.asm, optimizing each file with gco. Link all these files, along with the mylib library, to produce the executable myprog. Note that when processing an assembly file, -CO and -O3 are equivalent, since the only optimizations included in -O3 which are applicable to assembly files are those performed by gco. When processing a C source file, however, -CO causes the compactor to run but does not perform any optimizations in the compiler itself, which is not usually very useful. On the other hand, -O3 performs a variety of optimizations, including those performed by gco. A.2.4 Status Report At the end of the output code from gco is a comment line which describes what actions were taken on the input code. The following is a sample line and its explanation:!grdnt=b5+s10+a1+u0+v0+m111k+t2 b5: Number of basic blocks optimized. s10: Number of static optimizations performed. a1: Number of art substitutions performed. u0: Number of loops unrolled. v0: Number of loops vectorized. M111K: Amount of memory used during optimization (in kilobytes). T2: Duration of optimization in seconds. page 35