ARM Developer Suite ® Version 1.2 Getting Started Copyright © 1999-2001 ARM Limited. All rights reserved.
ARM Developer Suite Getting Started Copyright © 1999-2001 ARM Limited. All rights reserved. Release Information The following changes have been made to this book. Change History Date Issue Change October 1999 A Release 1.0 March 2000 B Release 1.0.1 October 2000 C Release 1.1 November 2001 D Release 1.2 Proprietary Notice Words and logos marked with ® or ™ are registered trademarks or trademarks owned by ARM Limited.
Contents ARM Developer Suite Getting Started Preface About this book .............................................................................................. vi Feedback ....................................................................................................... ix Chapter 1 Introduction 1.1 1.2 1.3 1.4 Chapter 2 Differences 2.1 2.2 2.3 2.4 Chapter 3 Overview .....................................................................................................
Contents 3.6 Chapter 4 Debugging the application with AXD ........................................................ 3-25 Migrating Projects from SDT to ADS 4.1 4.2 Converting makefiles and APM project files ............................................... 4-2 Moving your development project from SDT to ADS .................................. 4-4 Glossary iv Copyright © 1999-2001 ARM Limited. All rights reserved.
Preface This preface introduces the ARM Developer Suite (ADS) and its user documentation. It contains the following sections: • About this book on page vi • Feedback on page ix. ARM DUI 0064D Copyright © 1999-2001 ARM Limited. All rights reserved.
Preface About this book This book provides an overview of the ADS tools and documentation. Intended audience This book is written for all developers who are producing applications using ADS. It assumes that you are an experienced software developer. Using this book This book is organized into the following chapters: Chapter 1 Introduction Read this chapter for an introduction to ADS. The components of ADS and the printed and online documentation are described.
Preface monospace Denotes a permitted abbreviation for a command or option. The underlined text can be entered instead of the full command or option name. monospace italic Denotes arguments to commands and functions where the argument is to be replaced by a specific value. monospace bold Denotes language keywords when used outside example code. Further reading This section lists publications from ARM Limited that provide additional information on developing code for the ARM family of processors.
Preface • ARM ELF specification (SWS ESPC 0003). This is supplied in PDF format in install_directory\PDF\specs\ARMELF.pdf. • TIS DWARF 2 specification. This is supplied in PDF format in install_directory\PDF\specs\TIS-DWARF2.pdf. • ARM/Thumb® Procedure Call Standard specification. This is supplied in PDF format in install_directory\PDF\specs\ATPCS.pdf.
Preface Feedback ARM Limited welcomes feedback on both the ARM Developer Suite and its documentation. Feedback on the ARM Developer Suite If you have any problems with the ARM Developer Suite, please contact your supplier.
Preface x Copyright © 1999-2001 ARM Limited. All rights reserved.
Chapter 1 Introduction This chapter introduces the ARM Developer Suite Version 1.2 (ADS 1.2) and describes its software components and documentation. It contains the following sections: • About the ARM Developer Suite on page 1-2 • Printed documentation on page 1-5 • Online help on page 1-15. ARM DUI 0064D Copyright © 1999-2001 ARM Limited. All rights reserved.
Introduction 1.1 About the ARM Developer Suite ADS consists of a suite of applications, together with supporting documentation and examples, that enable you to write and debug applications for the ARM family of RISC processors. You can use ADS to develop, build, and debug C, C++, or ARM assembly language programs. 1.1.
Introduction armsd The ARM and Thumb symbolic debugger. This enables source level debugging of programs. You can single-step through C or assembly language source, set breakpoints and watchpoints, and examine program variables or memory. Rogue Wave C++ library The Rogue Wave library provides an implementation of the standard C++ library as defined in the ISO/IEC 14822:1998 International Standard for C++. For more information on the Rogue Wave library, see the online HTML documentation on the CD ROM.
Introduction Flash downloader Utility for downloading binary images to Flash memory on an ARM Integrator™ board or an ARM Development board (PID7T). Supporting software The following support software is provided to enable you to debug your programs, either under simulation, or on ARM-based hardware: ARMulator® The ARM core simulator. This provides instruction-accurate simulation of ARM processors, and enables ARM and Thumb executable programs to be run on non-native hardware.
Introduction 1.2 Printed documentation This section lists publications from both ARM Limited and third parties that provide additional information on developing code for the ARM family of processors. ARM periodically provides updates and corrections to its documentation. See http://www.arm.com for current errata sheets, addenda, and the ARM Frequently Asked Questions list. 1.2.1 ADS publications This book contains general information about ADS.
Introduction • CodeWarrior IDE Guide (ARM DUI 0065). This book provides tutorial and reference information on the CodeWarrior Integrated Development Environment. The CodeWarrior IDE is used to manage C, C++, and assembly language projects in ADS. The CodeWarrior IDE and guide are available only on Windows. • ADS Linker and Utilities Guide (ARM DUI 0151). This book provides reference information on the command-line options to the assembler, linker, compilers, and other ARM tools in ADS.
Introduction 1.3 Online documentation The ADS printed documentation is also available online as DynaText electronic books. The content of the DynaText manuals is identical to that of the printed and PDF documentation. In addition, documentation for the Rogue Wave C++ library is available in HTML format. See HTML on page 1-14 for more information. PDFs of the ADS manuals are installed only for a Full installation.
Introduction Figure 1-1 DynaText browser with list of available books Opening a book Double-click on a title in the book list to open the book. The table of contents for the book is displayed in the left panel and the text is displayed in the right panel (see Figure 1-2 on page 1-9). 1-8 Copyright © 1999-2001 ARM Limited. All rights reserved.
Introduction Figure 1-2 Opening a book Navigating through the book Click on a section in the table of contents to display the text for that section. For example, selecting C and C++ libraries displays the text for that section (see Figure 1-3 on page 1-10). ARM DUI 0064D Copyright © 1999-2001 ARM Limited. All rights reserved.
Introduction Figure 1-3 Selecting a section from the table of contents Navigating using hyperlinks Text in blue indicates a link that displays a different section of a book, or a different book. Plain blue text indicates that the link is within the current chapter. Underlined blue text indicates that the link is either to another chapter within the current book, or to a different book.
Introduction Figure 1-4 Using text links Displaying graphics Graphics are not displayed inline in the DynaText browser. If a graphic symbol is displayed, select it to display the linked graphic in its own window (see Figure 1-5). Figure 1-5 Link to a figure Clicking on the figure icon displays the figure in its own window (see Figure 1-6 on page 1-12). ARM DUI 0064D Copyright © 1999-2001 ARM Limited. All rights reserved.
Introduction Figure 1-6 Graphic displayed Navigating to a different book If the blue link text refers to a different book, clicking on the link text displays the linked book in its own window (see Figure 1-7 on page 1-13). 1-12 Copyright © 1999-2001 ARM Limited. All rights reserved.
Introduction Figure 1-7 Navigating to a different book Displaying help for DynaText Select Help → Reader Guide to display help on how to use DynaText. ARM DUI 0064D Copyright © 1999-2001 ARM Limited. All rights reserved.
Introduction 1.3.2 HTML The manuals for the Rogue Wave C++ library for ADS are provided on the CD-ROM in HTML files. Use a web browser, such as Netscape Communicator or Internet Explorer, to view these files. For example, select install_directory\Html\stdref\index.htm to display the HTML documentation for Rogue Wave (see Figure 1-8). Figure 1-8 HTML browser 1-14 Copyright © 1999-2001 ARM Limited. All rights reserved.
Introduction 1.4 Online help A Help menu is available for the Graphical User Interface components of ADS. Select Help → Contents to see a display of the main help topics available. The CodeWarrior IDE does not have a Contents menu item. Use the CodeWarrior IDE Help for ARM Developer Suite menu item instead.
Introduction Note Most help selections can be done by key presses or mouse clicks. 1.4.1 Context-sensitive help Context-sensitive help is available where appropriate. With the ADS component running, position the cursor on any field or button for which you need require help and press the F1 key on the keyboard. Alternatively, right-click over the feature you want help with and select What’s This? from the popup menu. If relevant online help is available it is displayed.
Chapter 2 Differences This chapter describes the major differences between SDT 2.50/2.51, ADS 1.0, ADS 1.1, and ADS 1.2. It contains the following sections: • Overview on page 2-2 • Changes between ADS 1.2 and ADS 1.1 on page 2-4 • Changes between ADS 1.1 and ADS 1.0 on page 2-13 • Changes between ADS 1.0 and SDT 2.50/2.51 on page 2-32. ARM DUI 0064D Copyright © 1999-2001 ARM Limited. All rights reserved.
Differences 2.1 Overview This chapter describes the changes that have been made between SDT 2.50/2.51 and ADS 1.0, between ADS 1.0 and ADS 1.1, and between ADS 1.1 and ADS 1.2. The most important differences between ADS 1.2 and ADS 1.1 are: • Support for ARM architecture v5TEJ. • The ARMulator provides ARM9EJ-S and ARM926EJ-S models, enabling the execution of Java byte codes under simulation. • Debuggers allow memory disassembly as Java bytecodes. • ADS now supported on Red Hat Linux 6.2 and 7.1.
Differences • Limited support for GNU images in AXD. • More components are license-managed, including the CodeWarrior IDE, fromELF, and armsd. • In the ADS 1.0.1 maintenance release, the default stack checking option for the assembler was changed to /noswst, to match the compilers. The most important differences between ADS 1.0 and SDT 2.50/2.51 are: • C and C++ libraries are supplied as binaries only. Selection of the appropriate library for the build option is automatic.
Differences 2.2 Changes between ADS 1.2 and ADS 1.1 This section describes changes between ADS 1.2 and ADS 1.1.
Differences Note ADS version 1.2 is the last release of ADS that supports Windows 95, Windows 98, and Solaris 2.6. Future versions of ADS will no longer be supported on these platforms. ADS 1.2 introduces the following functionality enhancements and new functionality: • Support for ARM architecture v5TEJ • Support for latest ARM cores • Support for Linux. Support for ARM architecture v5TEJ ADS 1.
Differences New or changed compiler options and pragmas The following compiler options are changed for ADS 1.2: This option can now output both assembly files (.s) and object code (.o). -asm -Ono_data_reorder Turns off the automatic reordering of top-level data items (for example, globals). The C/C++ compilers of ADS 1.1 and later now automatically reorder memory to eliminate wasted space between data items.
Differences __use_realtime_division() Selects a helper division routine that always executes in fewer than 45 cycles. Some applications require a faster worst-case cycle count at the expense of lower average performance. Headers C/C++ headers in the Include directory provide access to DSP functionality such as saturating addition and short (16x16 bit) multiplication. • armdsp.h provides functions corresponding exactly to the ARM9E instructions • dspfns.
Differences • • • New instructions and directives Access to C++ class members Improved warning on instruction restrictions. C compiler as preprocessor Assembly language files can now be preprocessed with the C preprocessor. New instructions and directives The assembler provides support for new ARM architecture v5TEJ processors. The instruction set is documented in the ADS Assembler Guide. The VFPv2 instructions can move two words of data either way between the ARM core and the VFP coprocessor.
Differences Changed linker behavior The following changes have been made to the linker behavior: • The linker accepts symbol definitions in a file. These symbols can provide global symbol values for a previously generated image file. • If a scatter-loading file is used with the linker, output section symbols such as Image$$RW$$Limit are not defined. Note If you are using scatter-loading files as input to the linker, you must reimplement __user_initial_stackheap() to set the heap and stack boundaries.
Differences New fromELF options This section gives a brief summary of new fromELF options for ADS 1.2. Refer to the ADS Linker and Utilities Guide for detailed information. The following fromELF option is new for ADS 1.2: -fieldoffsets This option produces an armasm file to the standard output that contains the C or C++ structure and class member offsets of the input ELF file. The input ELF file can be a relocatable object or an image.
Differences If you have written your own .ami ARMulator configuration files, to redefine cache or tightly coupled memory sizes, you need to make some changes to these files for them to work in ADS 1.2. See the ARMulator Reference chapter in the Debug Target Guide, ARMulator configuration files section for details. 2.2.9 Changes to the CodeWarrior IDE The CodeWarrior IDE has been upgraded to version 4.2.
Differences 2-12 • The Developer Guide has a new chapter on cached processors and tightly-coupled memory. • There is a separate Compilers and Libraries User Guide. • The Debugger Guide has been renamed as the AXD and armsd Debugger Guide and the ADW and ADU information removed. • The ARMulator Guide has been enhanced with more examples. Copyright © 1999-2001 ARM Limited. All rights reserved.
Differences 2.3 Changes between ADS 1.1 and ADS 1.0 This section describes changes between ADS 1.1 and ADS 1.0. It contains the following subsections: • Functionality enhancements and new functionality • Differences in default behavior on page 2-19 • Changes to the compilers and libraries on page 2-19 • Changes to the assembler on page 2-23 • Changes to the linker on page 2-25 • Changes to fromELF on page 2-26 • Changes to the debuggers on page 2-27 • Changes to ARMulator on page 2-29.
Differences • Reliably examine the contents of variables. Where the value of a variable is unavailable, it is described as such in the debugger. • Reliably set watchpoints on local variables. • Set breakpoints on closing parentheses to functions. • Set breakpoints on multiple statements on the same source line. Note The debug view is dependent on the optimization level selected. In addition, there are some restrictions to the debug view for ADW/ADU and armsd.
Differences .text .type $a,function @ or $t for Thumb $a: nop • The mapping symbol is in effect for the rest of the image, or until another mapping symbol is encountered. This provides a workaround for the disassembly and stepping restrictions listed above for images that contain only ARM code or only Thumb code. However, it means that literal pools are not detected and are disassembled as code, instead of being displayed as data. GCC does not generate call frame information.
Differences Code size improvements and improved optimization ADS 1.1 optimization improvements have improved code density for compiled code over ADS 1.0.1. A number of additional optimizations have been introduced. In particular the compilers now reorder top-level data items when this will save space. For example, if the following global variables are defined: char short char int a b c d = = = = 0x11; 0x2222; 0x33; 0x44444444; the ADS 1.
Differences connected. For example, the target can describe the number, name, and formatting requirements of its coprocessor registers to AXD, and AXD modifies its interface to represent the capabilities of the target. Note This means that AXD interface elements can change, depending on the target to which it is connected. Changes to memory alignment ADS 1.1 ensures that stack data is always 8-byte aligned. The new ATPCS requires that sp always points to 8-byte boundaries.
Differences The ADS 1.1 assembler supports two new directives to mark assembly units that contain functions that require, or preserve 8-byte alignment of the stack. This enables the linker to detect calls between code that does maintain 8-byte alignment, and code that does not maintain 8-byte alignment. PRESERVE8 Use this directive to mark assembly files that contain only functions that preserve 8-byte alignment of the stack.
Differences 2.3.2 Differences in default behavior This section describes how the default behavior of ADS 1.1 differs from that of ADS 1.0. The major changes are: 2.3.3 • The CodeWarrior IDE, fromELF, and armsd are now license-managed in the same way as other components of ADS. • The linker now unmangles C++ symbol names when generating diagnostic messages or listings. This is the default. You can use the -mangled option to change the behavior.
Differences New compiler options and pragmas This section gives a brief summary of new compiler options for ADS 1.1. Refer to the ADS Compilers and Libraries Guide for detailed information. The following compiler options are new for ADS 1.1: -split_ldm This option reduces the maximum number of registers transferred by LDM and STM instructions generated by the compiler. -O[no_]autoinline This option disables automatic inlining. It can be enabled with -Oautoinline.
Differences -fpu vfpv1 Selects hardware Vector Floating Point unit conforming to architecture VFPv1. This option is a synonym for -fpu vfp. It is not available for Thumb. -fpu vfpv2 Selects hardware Vector Floating Point unit conforming to architecture VFPv2. This option is not available for Thumb. #pragma import(symbol_name) This pragma generates an importing reference to symbol_name.
Differences • Tentative declarations are allowed by default in ADS 1.1 and later. In ADS 1.0.1, tentative declarations were disallowed by default unless -strict was specified. • Output from the -S and -S -fs options now displays standard register names, such as r0-r3, instead of their ATPCS equivalents (a1-a4). The output from -S -fs is now written to filename.txt, instead of filename.s. • When compiling with -zo, output sections now use the same name as the function that generates the section.
Differences • the compilers now place zero initialized global and static definitions such as: int a=0; in the ZI data area. The variables are initialized by the C libraries at run time. Previously such variables were placed in the RW area. Changes to the inline assemblers The inline assemblers support the ARMv5TE instructions. The inline assemblers do not support VFP floating-point instructions. Changes to the libraries The ARM C libraries are now compiled with the -split_ldm compiler option.
Differences New assembler options This section gives a brief summary of new assembler options for ADS 1.1. Refer to the ADS Assembler Guide for detailed information. The following assembler options are new for ADS 1.1: -fpu softvfp+vfp This option selects software floating-point library with pure-endian doubles, software floating-point linkage, and requiring a VFP unit. Select this option if you are interworking Thumb code with ARM code on a system that implements a VFP unit.
Differences Impact You must modify existing makefiles that use these options. Changed behavior ADS 1.1 introduces the following changes to the behavior of the assembler: • The assembler now faults a call to a GET directive from within a macro. • The assembler now faults the use of built-in variable names or predefined symbol names as a user symbol, such as a macro name. In ADS 1.0 the assembler silently ignored such usage.
Differences -mangled This option instructs the linker to display mangled C++ symbol names in diagnostic messages and listings. New scatter loading attributes The scatter load syntax has been extended to include a new attribute for execution regions: Fixed address. Both the load address and execution address of the region is specified by the base address (the region is a root region.
Differences New fromELF options This section gives a brief summary of new fromELF options for ADS 1.1. Refer to the ADS Linker and Utilities Guide for detailed information. The following fromELF options are new for ADS 1.1: -vhx This option outputs Byte Oriented (Verilog Memory Model) Hex Format. -base n This option specifies the base address of the output for Motorola S-record, and (-m32), Intel Hex (-i32) formats. memory_config This option outputs multiple files for multiple memory banks.
Differences • AXD displays the XScale coprocessors CP0, CP13, CP14, and CP15 in appropriate formats. • AXD data display has been enhanced to allow display in a choice of many different formats. • AXD now displays breakpoints and watchpoints in separate lists. • AXD persistence has been improved so that more of the previous GUI state can be restored at the start of a new session. • AXD can load standard ELF/DWARF2 images produced by the GNU toolchain.
Differences Changes to armsd The armsd debugger has been enhanced in the following ways: • armsd disassembles ARMv5TE instructions. • armsd is now license-managed through FLEXlm. • armsd can set and display the 40-bit XScale CP0 register, in a similar way to current ARM usage.
Differences • • • New configuration mechanism ARMulator byte order set from the debuggers on page 2-31 Changes to default behavior on page 2-31. License management The ARMulator is now license-managed at the model level, through FLEXlm. Integrated ARMulator and new processor models The ARMulator has been restructured to provide a single interface to all processor models that is easier to use and modify. All ARMulator models are accessible through a single target DLL (armulate.dll).
Differences In order to avoid loading files that are not meant for the armulate.dll product, it examines each file and checks that it starts with: ;; ARMulator configuration file type 3 ARMulator byte order set from the debuggers The ARMulator configuration dialog can now set the byte order of the simulated processor from within the debugger. Also, there are additional radio buttons in the configuration dialog to set the default startup behavior for ARMulator models that have a CP 15.
Differences 2.4 Changes between ADS 1.0 and SDT 2.50/2.51 This section describes the changes between ADS 1.0 and SDT 2.50/2.51. It contains the following subsections: • Functionality enhancements and new functionality • Differences in default behavior on page 2-42 • Changed compiler behavior on page 2-47 • Changed assembler behavior on page 2-52 • Changed linker behavior on page 2-55 • Obsolete components and standards on page 2-56. 2.4.1 Functionality enhancements and new functionality The ADS 1.
Differences Note BATS is no longer shipped with ADS 1.1 or later. The compiler performs instruction scheduling for ARM10 code by re-ordering machine instructions to gain maximum speed and minimize wait states. The linker uses BLX in interworking veneers when the underlying architecture (the ARM9E and ARM10, for example, have architecture 5) supports it.
Differences Note The order of the words in a little-endian double is different for FPA and VFP. If you select -fpu FPA or -fpu softFPA the SDT 2.50/2.51 format is used. If you select -fpu VFP or -fpu softVFP the new format is used. There is no functional difference between SoftFPA and SoftVFP. Both implement IEEE floating-point arithmetic by subroutine call, and both use the IEEE encoding of floating-point values into 32-bit words.
Differences Remote Debug Interface A new variant of the Remote Debug Interface (RDI 1.5.1) is introduced in ADS. The version used in SDT 2.50/2.51 was 1.5. The ADW debugger has been modified to function with RDI 1.0, RDI 1.5, or RDI 1.5.1 client DLLs. AXD works with RDI 1.5.1 targets only. Debug targets that are released as part of ADS (ARMulators, Remote_A, and Gateway) have been upgraded to RDI 1.5.1. Impact Third-party DLLs written to use RDI 1.
Differences • Improved stack-unwinding due to the use of DWARF2 descriptions. In ADS, all standard library functions carry DWARF frame unwinding descriptions with them. These are always generated by ADS compilers and there is new assembler support in ADS to facilitate their generation for hand-written assembly language. Impact AXD can debug RDI 1.5.1 targets only. All ARM-supplied debug targets (Multi-ICE, ARMulator, Remote_A, and gateway) support RDI 1.5.1. For non-ARM debug targets that support RDI 1.
Differences Hardware other than serial, parallel, or ethernet ports can be used to communicate with Angel. The GUI interface for Remote_A is extended into the loaded driver. Libraries All Libraries (C, C++, math, and floating-point) are released as a set of object code variants that cover all possible choices of Procedure Call Standard and all processor architecture versions. A limited set of variants is required because the libraries have been restructured to remove the necessity for some combinations.
Differences Impact The linker supports the deprecated ALF library format. Use armar for new libraries and migrate your existing libraries to armar. CodeWarrior IDE ARM has licensed the CodeWarrior IDE from Metrowerks and is making this available within ADS. This replaces APM on Windows platforms. (It is not available on UNIX platforms). The CodeWarrior IDE provides a simple, versatile, graphical user interface for managing your software development projects.
Differences — simple Overlay (OVERLAY). • Direct support for ROPI and RWPI procedure call standard variants. • Support for outputting symbol definitions from a link step and reading them in a later link step (support for system code at a fixed address). Impact Update your projects or makefiles to link with the appropriate options. In most cases you will not have to change your source code to use the new options.
Differences C++ compilers The C++ compilers included with ADS inherit all the benefits of the C compiler. The following additional improvements have been introduced since C++ version 1.10: • Rogue Wave Library 2.01. This includes the Rogue Wave iostream implementation. The iostream implementation supplied with C++ version 1.10 has been removed. Replace references to stream.h and iostream.h with iostream. • Support for the EC++ informal standard. • Updated vtables to support ROPI.
Differences License management ADS components are license-managed by FLEXlm. See the ADS Installation and License Management Guide for more information. ARM DUI 0064D Copyright © 1999-2001 ARM Limited. All rights reserved.
Differences 2.4.2 Differences in default behavior The differences in the default behavior of ADS compared to SDT 2.50/2.
Differences — a short enum type — a struct containing only fields of short alignment. If possible, you should recompile your SDT 2.50/2.51 object using ADS. If you cannot recompile your object in ADS, you can compile your ADS code with the -zas4 option to revert to SDT 2.50/2.51 behavior. — Note Code compiled with the -zas4 option in ADS is incompatible with other ADS objects, including the ADS C++ libraries. — The -zas option is deprecated in ADS 1.2 and will not be supported in future releases.
Differences Entry point set by linker option The -entry option sets the entry point for an image. There can be only one instance of the -entry option to the linker. Impact Multiple -entry settings generate an error. ADW ADW now defaults to VFP mode for the display of floating-point and double values, and for floating-point registers. The SDT 2.50/2.
Differences Floating-point exceptions The ADS tools have been changed to conform to the IEEE specification. The SDT2.50/2.51 tools set the default response to floating-point Invalid-Operation, Divide-By-Zero and Overflow to be a trap causing program termination. This is contrary to IEEE 754 section 7, that states that “The default response to an exception shall be to proceed without a trap.” Impact To restore exception handling to the SDT 2.50/2.
Differences The variable is used only to specify alternative search paths to the debuggers. You must use the following conventions when specifying search paths: • Enclose the full pathname in double quotes. • In ADW and armsd under Windows DOS, escape the backslash directory separator with another backslash character. For example: "c:\\mysource\\src1" • Separate multiple pathnames with a semicolon, not with a space character.
Differences 2.4.3 Changed compiler behavior This section describes compiler behavior that is new, changed, deprecated, or obsolete. Obsolete features are identified explicitly. Their use is faulted in ADS. Deprecated features will be made obsolete in future releases. Their use is warned about in ADS.
Differences Table 2-1 Procedure call standard qualifiers (continued) ADS form SDT 2.50/2.51 equivalent Not available. [no]fpregargs Obsolete. Now always narrow. narrow, wide No direct equivalent, use -rwpi. [non]reentrant Impact Update your projects or makefiles to compile with the appropriate options. In most cases you do not have to change your source code to use the new options. Check the assembler, compiler, and linker options for your new or migrated projects as the defaults for ADS 1.
Differences -zinumber -gxletter -dwarf -aof -asd -MD -cfront -pcc -fussy -pedantic -fw -zanumber -zt -zznumber -zztnumber -zap -zat -zrnumber -fz Replaced by -Ospace and -Otime. Replaced by the -O[0|1|2] options. Use -dwarf2 (or -dwarf1). Output AOF. Output ASD format debug tables. Generate APM dependency. Select Cfront-style C++. Select Berkeley PCC. Synonym for -strict. Synonym for -strict. Make string literals writable. Use -memaccess instead. The default behavior for ADS 1.
Differences -proc, -arch Select processor or architecture. Use -cpu instead. -zasnum Align structures on at least a num-byte boundary (1, 2, 4, or 8). The default is now 1 (align only as strictly as the contents of the structure require). Impact You can still output DWARF1 debug tables. However, the functionality of these output files when used with the new debuggers might be reduced. Use DWARF2 format for new projects and update your existing tools to use the DWARF2 format.
Differences Table 2-2 Obsolete predefined macros (continued) Predefine Status Comments __APCS_REENT Obsolete Relates to obsolete APCS/TPCS. No ATPCS equivalent. __APCS_NOSWST Obsolete Relates to obsolete APCS/TPCS. Use new __APCS_SWST. __CFRONT_LIKE Obsolete The option -cfront is now obsolete. __DIALECT_PCC Obsolete The option -pcc is now obsolete. __DIALECT_FUSSY Obsolete The option -fussy is now obsolete. The new predefined macros are listed in Table 2-3.
Differences 2.4.4 Changed assembler behavior This section describes assembler behavior that is changed, deprecated, or obsolete. Obsolete features are identified explicitly. Their use is faulted in ADS. Deprecated features will be made obsolete in future releases. Their use is warned about in ADS. New or changed assembler behavior The following enhancements and changes are available in the assembler: • The assembler provides new ATPCS command-line options similar to those for the compilers.
Differences ARM DUI 0064D • There are new synonyms FIELD and SPACE for # and % directives. • Directives are now accepted in all upper case, or all lower case, but not a mixture. Previously, only the upper case form was accepted. • The EXPORT directive may have a new attribute, WEAK. This defines the exported symbol as a WEAK symbol in ELF. • The semantics of the EXTERN and IMPORT directives have changed and they are no longer synonyms.
Differences Features of the SDT assembler not supported The following assembly language features are no longer supported and are faulted: • AREA directive with attribute ABS, BASED, A32bit, HALFWORD, INTERWORK, PIC, REENTRANT — ABS has been withdrawn because it conflicts with the linker scatter-loading mechanism.
Differences Select architecture (use -cpu instead). -arch Impact Use DWARF2 format for new projects and update your existing tools to use the DWARF2 format. 2.4.5 Changed linker behavior This section describes linker behavior that is changed, deprecated, or obsolete. Obsolete features are identified explicitly. Their use is faulted in ADS. Deprecated features will be made obsolete in future releases. Their use is warned about in ADS.
Differences -keep -locals -nolocals -xreffrom -xrefto -strict -symdefs Specify sections to be retained even if unused Add local symbols to image symbol table Remove local symbols from image symbol table List section cross references in image from a section List section cross references in image to a section Strict compliance to build attribute rules Create, or read, a list of symbol definitions.
Differences APM APM is not provided. Impact Use the CodeWarrior IDE or a make utility. Armmake Armmake is not provided. There is no longer a need to rebuild the C Libraries, therefore the ARM-specific make utility has been removed. Impact None. Use nmake, make, or gnumake if you want to use a make utility. Armlib The ARM librarian, armlib is not provided. It has been replace by a new utility, armar, that creates ELF ar files.
Differences 26-bit addressing ADS does not support 26-bit addressing. Removal of 26-bit support has enabled a more efficient ATPCS to be designed. Impact Continue to use SDT2.50/2.51 if you need 26-bit support. AOF, AIF, IHF, and Plain Binary image formats The SDT 2.50/2.51 linker gave warnings when asked to generate an AIF image, a binary AIF image, an IHF image, or a plain binary image. The ADS linker refuses to generate these images and is now a pure ELF linker.
Chapter 3 Creating an Application This chapter describes how to create an application using ADS. It contains the following sections: • Using the CodeWarrior IDE on page 3-2 • Building from the command line on page 3-14 • Using ARM libraries on page 3-21 • Using your own libraries on page 3-24 • Debugging the application with AXD on page 3-25. ARM DUI 0064D Copyright © 1999-2001 ARM Limited. All rights reserved.
Creating an Application 3.1 Using the CodeWarrior IDE The CodeWarrior IDE provides a simple, versatile, graphical user interface for managing your software development projects. You can use the CodeWarrior IDE for the ARM Developer Suite to develop C, C++, and ARM assembly language code targeted at ARM processors. The CodeWarrior IDE enables you to configure the ARM tools to compile, assemble, and link your project code.
Creating an Application 3.2 Creating and building a simple project This section describes how to create and build a simple project. It uses source files from the dhryansi example supplied with ADS 1.2 to give an introduction to configuring tool options and using build targets in the CodeWarrior IDE. Note This example assumes that you have installed the example code supplied with ADS 1.2, and that you have installed in the default installation directory.
Creating an Application Figure 3-1 New dialog 3. Ensure that the Project tab is selected. The available ARM project stationery is listed in the left of the dialog (see Figure 3-1), along with the Empty Project stationery and the Makefile Importer Wizard. See the CodeWarrior IDE Guide for more information on using empty projects and the Makefile Importer Wizard. 4. Select ARM Executable Image from the list of project stationery. 5. Click the Set… button next to the Location field.
Creating an Application 6. Navigate to the directory where you want to save the project and enter a project name, for example My_Project. Leave the Create Folder checkbox selected. 7. Click Save. The CodeWarrior IDE sets the Project Name field and Location path in the New dialog box. The Location path is used as a default when you create additional projects. 8. Click OK.
Creating an Application Figure 3-4 Select files to add… dialog 4. Click Open. The CodeWarrior IDE displays an Add Files dialog (Figure 3-5). The dialog contains a checkbox for each build target defined in the current project. In this example, the dialog contains three checkboxes corresponding to the three build targets defined in the ARM Executable Image project stationery. Figure 3-5 Add Files 5. 3-6 Leave all the build target checkboxes selected and click OK.
Creating an Application Figure 3-6 Project messages window The access paths for each build target define the directories that are searched for source and header files. See the CodeWarrior IDE Guide for details. Note You do not need to add the header files for the dhryansi project because the CodeWarrior IDE locates them in the newly added access path. However, you can add header files explicitly if you want. 6. Ensure that the Files tab is selected in the project window.
Creating an Application Build target settings must be selected separately for each build target in your project. To set build target options for the dhryansi example: 1. Ensure that the DebugRel build target is currently selected. By default, the DebugRel build target is selected when you create a new project based on the ARM project stationery. The currently selected build target is displayed in the Build Target drop-down list in the project toolbar (Figure 3-8).
Creating an Application Figure 3-9 DebugRel Settings 3. Click the ARM C Compiler entry in the Target Settings Panels list to display the configuration panel for the C compilers. The Target and Source panel is displayed (Figure 3-10). The panel consists of a number of tabbed panes containing groups of configuration options. For this example, the dhryansi source requires that you set a predefined macro before it will compile.
Creating an Application 4. Click the Preprocessor tab to display a list of predefined macros (Figure 3-11). Figure 3-11 ARM C compiler preprocessor panel 5. Type MSC_CLOCK into the text field beneath the List of #DEFINES and click Add to define the MSC_CLOCK macro. The CodeWarrior IDE adds MSC_CLOCK to the List of #DEFINES. The Equivalent Command Line text box displays the compiler command-line option required to define MSC_CLOCK (Figure 3-12). Figure 3-12 MSC_CLOCK defined 6.
Creating an Application Note You can also cut and paste build target settings into the Equivalent Command Line text box. Press the Enter key to set the options and update the panel controls. Be careful not to copy command-line options that are inappropriate, such as the optimization and debug settings, from one build target to another. Leave the Release Target settings panel open after you have saved your changes. 5.
Creating an Application Note This example has shown how to use the configuration dialogs to set options for individual build targets. There are configuration panels available for most of the ADS toolchain, including the linker, fromELF, and the assembler. You can use the configuration panels to specify most options available in the tools, including: • procedure call options • the structure of output images • the linker and postlinker to use • the ARM debugger to call from the CodeWarrior IDE.
Creating an Application 3.2.5 Debugging the project By default, the ARM project stationery is configured to call the AXD debugger to debug and run images built from the CodeWarrior IDE. You can configure the debugger to be called using the ARM Debugger configuration panels for each build target. See the CodeWarrior IDE Guide for details. To execute and debug your example project: ARM DUI 0064D 1. Ensure that the project window is the currently active window. 2.
Creating an Application 3.3 Building from the command line This section describes how to build an application from the command line.
Creating an Application 2. Link the image using the following command: armlink main.o -o embed.axf where: -o 3. ARM DUI 0064D Specifies the output file as embed.axf. Use armsd or AXD to load and test the image. Copyright © 1999-2001 ARM Limited. All rights reserved.
Creating an Application 3.3.2 Using the assembler from the command line The basic syntax to use the ARM assembler (armasm) from the command-line is: armasm {inputfile} For example, to assemble the code in a file called myfile.s, type: armasm -list myfile.lst myfile.s This produces an object file called myfile.o, and a listing file called myfile.lst. For full details of the command-line options and syntax, refer to the ADS Assembler Guide.
Creating an Application Building the example To build the example: 1. Enter the code using any text editor and save the file in your current working directory as addreg.s. 2. Type armasm -list addreg.lst addreg.s at the command prompt to assemble the source file. 3. Type armlink addreg.o -o addreg to link the file. Running the example in the debugger To load and run the example in the debugger: 1. Type armsd addreg to load the module into the command-line debugger. 2.
Creating an Application The default output from the linker is a non-relocatable image where the code starts at 0x8000 and the data section is placed immediately after the code. You can specify exactly where the code and data sections are located by using linker options or a scatter-load description file. Linker input and output Input to armlink consists of: • one or more object files in ELF Object Format • optionally, one or more libraries created by armar.
Creating an Application -rw-base address This option sets the execution addresses of the region containing the RW output section at address. The default address is at the end of the RW section. -rwpi This option makes the load and execution region containing the RW and ZI output section position-independent. If this option is not used the region is marked as absolute. The -rwpi option is ignored if -rw-base is not also used. Usually each writable input section must be read-write position-independent.
Creating an Application 3.3.4 Using the CodeWarrior IDE from the command line In some cases you might not require the Graphical User Interface of the CodeWarrior IDE, for example, when a project is part of a larger system that must be built automatically without user interaction. See the CodeWarrior IDE Guide for information on using the CodeWarrior IDE from the command line. 3.3.5 Invoking AXD from the command line AXD can be invoked from the command line.
Creating an Application 3.4 Using ARM libraries The following run-time libraries are provided to support compiled C and C++: ANSI C C++ The C libraries consist of: • The functions defined by the ISO C library standard. • Target-dependent functions used to implement the C library functions in the semihosted execution environment. You can redefine these functions in your own application. • Helper functions used by the C and C++ compilers.
Creating an Application • 3.4.1 Note The ARM C libraries are supplied in binary form only. • The ARM libraries should not be modified. If you want to create a new implementation of a library function, place the new function in an object file, or your own library, and include it when you link the application. Your version of the function will be used instead of the standard library version.
Creating an Application You must re-implement functions that the C library uses to insulate itself from target dependencies. For example, if you use printf() you must re-implement fputc(). If you do not use the higher level input/output functions like printf(), you do not have to re-implement the lower level functions like fputc().
Creating an Application 3.5 Using your own libraries The ARM librarian, armar, enables sets of ELF object files to be collected together and maintained in libraries. Such a library can then be passed to armlink in place of several object files. However, linking with an object library file does not necessarily produce the same results as linking with all the object files collected into the object library file.
Creating an Application 3.6 Debugging the application with AXD AXD enables you to run and debug your image using any of the following debug targets: • ARMulator (the default) • Multi-ICE • EmbeddedICE • Angel debug monitor • Gateway. See the AXD and armsd Debuggers Guide for more information on using the debuggers. 3.6.
Creating an Application Figure 3-14 Loading an image Stepping through an application Use Execute → Step to step through the application (Figure 3-15 on page 3-27). 3-26 Copyright © 1999-2001 ARM Limited. All rights reserved.
Creating an Application Figure 3-15 The Execute menu The disassembled code is displayed and a pointer indicates the current position (Figure 3-16 on page 3-28). Use Step (F10) to execute the next instruction. ARM DUI 0064D Copyright © 1999-2001 ARM Limited. All rights reserved.
Creating an Application Figure 3-16 Disassembly Processor view Use the Processor Views menu to monitor the program data during the debug (Figure 3-17). Figure 3-17 Processor Views menu For example, use Processor Views → Registers to display a dialog showing the register contents (Figure 3-18 on page 3-29). 3-28 Copyright © 1999-2001 ARM Limited. All rights reserved.
Creating an Application Figure 3-18 Viewing register contents 3.6.2 Configuring ARMulator for AXD When you run AXD for the first time, an ARMulator debugging session starts by default, with ARMulator configured by settings held in a default configuration file. For information on reconfiguring ARMulator, returning to ARMulator after using another debug target, and selecting and configuring other debug targets, refer to the AXD and armsd Debuggers Guide. ARM DUI 0064D Copyright © 1999-2001 ARM Limited.
Creating an Application 3-30 Copyright © 1999-2001 ARM Limited. All rights reserved.
Chapter 4 Migrating Projects from SDT to ADS This chapter describes some of the issues involved when converting an existing project built with the ARM Software Development Toolkit (SDT) to the ARM Developer Suite (ADS). It also shows some of the diagnostic messages which you might see when converting a project, and suggests workarounds for common problems. It is strongly recommended that you read Chapter 2 Differences before reading this chapter.
Migrating Projects from SDT to ADS 4.1 Converting makefiles and APM project files This section describes: • Converting APM project files (Windows only) • Converting makefiles (Windows & Unix) on page 4-3. 4.1.1 Converting APM project files (Windows only) SDT projects are managed using the ARM Project Manager (APM). ADS projects are managed using the CodeWarrior IDE. You cannot use existing APM projects, and there is no automatic way to convert APM .apj project files to CodeWarrior IDE .
Migrating Projects from SDT to ADS 7. Check any other assembler, compiler, and linker options displayed on the command line. Some of the defaults have changed. See the appropriate sections in Moving your development project from SDT to ADS on page 4-4 for more information on how default compiler, linker, and assembler options have changed between SDT and ADS. 8. Create a new CodeWarrior project. See Using the CodeWarrior IDE on page 3-2 for an introduction to the CodeWarrior IDE.
Migrating Projects from SDT to ADS 4.2 Moving your development project from SDT to ADS The following sections describe the most important changes between ADS and SDT, and describe how to change your tool options and code to work with ADS: • Compiling • Assembling on page 4-7 • Linking on page 4-8 • Initialization of C Libraries and Execution Regions on page 4-13 • Calling constructors and destructors for top-level C++ objects on page 4-16. 4.2.
Migrating Projects from SDT to ADS In ADS, all code is compiled as -apcs /narrow. The -apcs /wide option was obsolete in SDT 2.50 and SDT 2.51, and is no longer supported. If you see: Error: C3057E: bad option '-apcs /narrow ': ignored then remove the /narrow qualifier from your compiler command line. See Table 2-1 on page 2-47 for more information on changed APCS qualifiers.
Migrating Projects from SDT to ADS In ADS, -zz0, -zt, -zzt0, and -zz-1 are faulted. Remove these options from your compiler command line.. This change might affect linking if you are using a scatter-load description file. See Linking on page 4-8 for more information. -fc In the SDT 2.11a, and earlier toolkits, the -fc option enabled limited pcc support. This is redundant in SDT 2.50 and SDT 2.51.
Migrating Projects from SDT to ADS 4.2.2 Assembling Some assembler features have changed between SDT and ADS. For a full list of changes between SDT and ADS 1.2, see Chapter 2 Differences. The following sections describe changes that most frequently cause problems when moving to ADS: • Interworking • FUNCTION directive • String Literals and $. Interworking In SDT, assembly language code intended for interworking is marked with the INTERWORK attribute on the AREA directive.
Migrating Projects from SDT to ADS to: basesym SETS "|Image$$$$":CC:namecp:CC:"$$$$Base|" See Changed assembler behavior on page 2-52, and the ADS Assembler Guide for more information. Note In ADS, RO/RW/ZI initialization is usually done by the C library. You might not need your SDT initialization code. See Initialization of C Libraries and Execution Regions on page 4-13 for more information. 4.2.3 Linking Some linker features have changed between SDT and ADS.
Migrating Projects from SDT to ADS • The linker normally finds the correct C or C++ libraries to link with, and it might use several libraries, so do not specify the C or C++ libraries on the linker command line. For example, change: armlink obj1.o obj2.o armlib_cn.32l -o image.axf to: armlink obj1.o obj2.o -o image.axf Change -info size to -info sizes In SDT 2.50 and SDT 2.51, the linker accepts either size or sizes as a qualifier to the -info option. In ADS, only sizes is accepted.
Migrating Projects from SDT to ADS Error: L6242E: Cannot link object _main.o as its attributes are incompatible with the image attributes. If possible, it is recommended that you rebuild your entire project, including the old objects, with ADS. However, if you do not have the source code for an object or library, try rebuilding your ADS application code with the -fpu softfpa option. See Object and library compatibility on page 2-42 for a detailed explanation of how and when you can link old library code.
Migrating Projects from SDT to ADS The ADS C library defines an entry point at __main(). If you specify additional entry points, and do not explicitly specify an initial entry point with the -entry option, the linker cannot determine which entry point to use as the initial entry point and gives a warning: Image does not have an entry point. (Not specified or not set due to multiple choices) You can select one of the entry points as the initial image entry point.
Migrating Projects from SDT to ADS Peripherals 0x02000000 { periph.o (+RW) ; Variables for accessing ; peripherals } 32bitRAM 0x0000 { vectors.o (Vect,+FIRST) ; vector table int_handler.o (+RO) ; interrupt handler } 16bitRAM 0x2000 { * (+RW,+ZI) ; program variables } } If periph.c contains only uninitialized global variables, and this scatter-load description file is used with ADS, the linker gives the following warning message: Warning : L6314W: C:\scatter.
Migrating Projects from SDT to ADS Section naming in scatter-loading You should not use compiler-generated section names in scatter-loading descriptions. The names generated in ADS are different to those generated in SDT. ADS uses standard ELF section names: • C$$code is now .text • C$$data is now .data • C$$zidata is now .bss • C$$constdata is now .constdata. You should specify code/data sections in scatter files using the names and attributes of objects (unless you are using -zo).
Migrating Projects from SDT to ADS There are no Embedded C libraries supplied with ADS because the standard C libraries can be retargeted for embedded use. However, the standard libraries must be initialized. This is normally done through main(). This means that you must have a main() function if you use the C libraries in ADS. If you are moving a project from SDT to ADS, rename C_Entry() to main().
Migrating Projects from SDT to ADS IMPORT __rt_entry EXPORT __main ENTRY __main B __rt_entry See the description of how C and C++ programs use the library functions in the C library chapter of the ADS Compilers and Libraries Guide. Memory Mapped Peripherals If you have C variables mapped onto the registers of, for example, memory mapped peripherals, you can instruct the ADS library not to zero-initialize them. Example 4-2 defines a C structure mapped onto some peripheral registers in a file called iovar.
Migrating Projects from SDT to ADS 4.2.5 Calling constructors and destructors for top-level C++ objects If you are using ARM C++ with SDT you must: • call constructors for top-level C++ library objects with an explicit call to __cpp_initialise() • call destructors for top-level C++ library objects with an explicit call to __cpp_finalise(). This is described in the SDT 2.51 Errata PDF, and in Application Note 74 Using ARM C++ in Embedded Systems.
Migrating Projects from SDT to ADS readsyms embed.axf pc = 0x0 cpsr = %IFt_SCVC (in SDT this was cpsr = %IFt_SVC32) $vector_catch = 0 $semihosting_enabled = 0 $top_of_memory = 0x40000 For AXD the equivalent commands are: loadsymbols embed.axf setpc 0 sreg cpsr 0xd3 spp vector_catch 0 spp semihosting_enabled 0 let $top_of_memory 0x40000 For other examples, go to the technical support area on the ARM web site at www.arm.com. ARM DUI 0064D Copyright © 1999-2001 ARM Limited. All rights reserved.
Migrating Projects from SDT to ADS 4-18 Copyright © 1999-2001 ARM Limited. All rights reserved.
Glossary ADS See ARM Developer Suite. AFS See ARM Firmware Suite. AIF ARM Image Format ALF ARM Library Format Angel A debug monitor that enables you to develop and debug applications running on ARM-based hardware. Angel can debug applications running in either ARM state or Thumb state. ANSI American National Standards Institute. An organization that specifies standards for, among other things, computer software. AOF See ARM Object Format.
Glossary ARM Developer Suite A suite of applications, together with supporting documentation and examples, that enable you to write and debug applications for the ARM family of RISC processors. ARM eXtended Debugger Debugger software from ARM that enables you to make use of a debug agent in order to examine and control the execution of software running on a debug target. AXD is supplied in both Windows and UNIX versions.
Glossary Big-endian Memory organization in which the least significant byte of a word is at a higher address than the most significant byte Bit Binary Digit Breakpoint A location in the image. If execution reaches this location, the debugger halts execution of the image. See also: Watchpoint.
Glossary DSP Digital Signal Processor DWARF Debug With Arbitrary Record Format Dynamic Linked Library A collection of programs, any of which can be called when needed by an executing program. A small program that helps a larger program communicate with a device such as a printer or keyboard is often packaged as a DLL. ELF Executable and Linking Format EmbeddedICE The additional hardware provided by debuggable ARM processors to aid debugging Exception Handles an event.
Glossary Immediate values Values which are encoded directly in the instruction and used as numeric data when the instruction is executed. Many ARM and Thumb instructions allow small numeric values to be encoded as immediate values within the instruction that operates on them. Inline Functions that are repeated in code each time they are used rather than having a common subroutine. Assembler code placed within a C or C++ program.
Glossary Processor Status Register See Program Status Register. Program Counter (PC) Integer register R15 (or bits[25:2] of R15 on 26-bit architectures) Program Status Register (PSR) Contains some information about the current program and some information about the current processor. Often, therefore, also referred to as Processor Status Register. Also referred to as Current PSR (CPSR), to emphasize the distinction between it and the Saved PSR (SPSR).
Glossary Rounding modes Specify how the exact result of a floating-point operation is rounded to a value which is representable in the destination format RPS Reference Peripheral System RWPI See Read/Write Position Independent. Saved Program Status Register See Program Status Register.
Glossary Thumb instruction A halfword which specifies an operation for an ARM processor in Thumb state to perform. Thumb instructions must be halfword-aligned. Thumb state A processor that is executing Thumb (16-bit) instructions is operating in Thumb state See also ARM state. Translation tables Tables held in memory that define the properties of memory areas of various sizes from 1KB to 1MB.
Index A ANSI C library 1-4 ISO C standard APM project files converting 4-2 applib 3-21 ar 1-4 armar 1-3, 3-24 armasm 1-2 armcc 1-2 armcpp 1-2 armlib 3-21 armlink 1-2 armprof 1-3 armsd 1-3 ARMulator 1-4 configuring for AXD 3-29 Assembler differences 2-40, 2-52 enhancements 2-40, 2-52 mode changing 3-16 using from the command line 3-16 ARM DUI 0064D AXD 1-3 starting 3-25 using B Books Assembler Guide 1-5 CodeWarrior IDE Guide 1-6 Compiler, Linker, and Utilities Guide 1-5 Debug Target Guide 1-5 Debuggers G
Index Converting from SDT to ADS APM project files 4-2 assembling 4-7 compiling 4-4 initialization 4-13 linking 4-8 makefiles 4-3 C++ library Rogue Wave 3-22 source 3-22 M Flash downloader 1-4 fromELF 1-3 Makefiles, converting 4-3 Memory mapped peripherals 4-15 G O GNU 2-14, 2-28 Obsolete assembler options 2-54 compiler macros 2-50 compiler options 2-48 components 2-56 file formats 2-58 linker options 2-56 standards 2-56 Online documentation 1-7 H D Hiding and renaming symbols 2-25 Debuggers AXD
Index Stepping through an application 3-26 Symbols linker 2-25 T tcc 1-2 tcpp 1-2 ARM DUI 0064D Copyright © 1999-2001 ARM Limited. All rights reserved.
Index Index-4 Copyright © 1999-2001 ARM Limited. All rights reserved.
