文件列表:

dsp(5416)\cgtools\include\access.h (33, 2001-05-08)
dsp(5416)\cgtools\include\assert.h (1856, 2001-05-08)
dsp(5416)\cgtools\include\cassert (857, 2001-05-08)
dsp(5416)\cgtools\include\cctype (1432, 2001-05-08)
dsp(5416)\cgtools\include\cerrno (809, 2001-05-08)
dsp(5416)\cgtools\include\cfloat (381, 2001-05-08)
dsp(5416)\cgtools\include\climits (633, 2001-05-08)
dsp(5416)\cgtools\include\cmath (4569, 2001-05-08)
dsp(5416)\cgtools\include\cmathf (5019, 2001-05-08)
dsp(5416)\cgtools\include\cmathl (5419, 2001-05-08)
dsp(5416)\cgtools\include\csetjmp (827, 2001-05-08)
dsp(5416)\cgtools\include\cstdarg (828, 2001-05-08)
dsp(5416)\cgtools\include\cstddef (827, 2001-05-08)
dsp(5416)\cgtools\include\cstdio (832, 2001-05-08)
dsp(5416)\cgtools\include\cstdlib (829, 2001-05-08)
dsp(5416)\cgtools\include\cstring (828, 2001-05-08)
dsp(5416)\cgtools\include\ctime (828, 2001-05-08)
dsp(5416)\cgtools\include\ctype.h (5867, 2001-05-08)
dsp(5416)\cgtools\include\errno.h (1047, 2001-05-08)
dsp(5416)\cgtools\include\exception (367, 2001-05-08)
dsp(5416)\cgtools\include\file.h (2153, 2001-05-08)
dsp(5416)\cgtools\include\float.h (2801, 2001-05-08)
dsp(5416)\cgtools\include\intrindefs.h (5339, 2001-05-08)
dsp(5416)\cgtools\include\ldcio.h (3370, 2001-05-08)
dsp(5416)\cgtools\include\limits.h (1459, 2001-05-08)
dsp(5416)\cgtools\include\linkage.h (872, 2001-05-08)
dsp(5416)\cgtools\include\math.h (2774, 2001-05-08)
dsp(5416)\cgtools\include\new (1751, 2001-05-08)
dsp(5416)\cgtools\include\setjmp.h (1095, 2001-05-08)
dsp(5416)\cgtools\include\stdarg.h (2308, 2001-05-08)
dsp(5416)\cgtools\include\stddef.h (1366, 2001-05-08)
dsp(5416)\cgtools\include\stdexcept (367, 2001-05-08)
dsp(5416)\cgtools\include\stdio.h (12662, 2001-05-08)
dsp(5416)\cgtools\include\stdlib.h (4445, 2001-05-08)
dsp(5416)\cgtools\include\string.h (9872, 2001-05-08)
dsp(5416)\cgtools\include\time.h (3295, 2001-05-08)
dsp(5416)\cgtools\include\typeinfo (1532, 2001-05-08)
dsp(5416)\cgtools\include\unaccess.h (35, 2001-05-08)
dsp(5416)\cgtools\lib\lnk.cmd (3975, 2001-05-08)
dsp(5416)\cgtools\lib\rts.lib (177494, 2001-05-08)
... ...

----------------------------------------------------------------------- TEXAS INSTRUMENTS DIGITAL SIGNAL PROCESSOR DEVELOPMENT TOOLS TMS320C54x Code Generation Tools, Version 3.70 ----------------------------------------------------------------------- Thank you for choosing Texas Instruments software development tools. It is our goal to provide you with the most useful and efficient development tools from which to develop your applications around Texas Instruments processors. For questions or technical support, please contact Texas Instruments Customer Support: E-mail: support@micro.ti.com Phone: (412) 380-1550 Fax: (412) 380-1536 The preferred method for contacting Customer Support is through e-mail. Please include: * Your name * Company name * Phone number * E-mail address * Name and version of the tool * A brief problem description * A code example that reproduces the problem ------------------------------------------------------------------------------ Table of Contents ------------------------------------------------------------------------------ SECTION 1: RELEASE ENHANCEMENTS 1.1: New for v3.70 1.1.1: New .version directive value 1.1.2: C++ support 1.1.3: Additional Shell Options for C++ 1.1.4: Global C++ Variable Construction 1.1.5: C++ Syntax for Pragmas 1.1.6: Generating Linknames 1.1.7: C++ Name Demangler 1.1.8: Unified Runtime Library 1.1.9: Known C++ bugs 1.2: Profiling Support 1.3: Additional Shell Options 1.4: Shell Options No Longer Supported 1.5: Updated Shell Option (-pk) 1.6: Using Inline Function Expansion 1.7: Intrinsics 1.7.1: Changes to ETSI Basicop Support 1.8: Built-in Math Functions 1.9: Pipeline Conflict Handling 1.10: Pragma IDENT 1.11: C Environment for Interrupt Routines 1.12: Allocation Using Multiple Memory Areas 1.12.1 Automatic Splitting of Code/Data Among Non-Contiguous Memory Areas 1.13: New DWARF Symbolic Debug Switch: -gw SECTION 2: KNOWN PROBLEMS SECTION 3: FIXED PROBLEMS --------------------------------------------------------------------- SECTION 1: RELEASE ENHANCEMENTS --------------------------------------------------------------------- This section describes the new features found in this release of the TMS320C54x Code Generation tools. ----------------------------------------- SECTION 1.1 NEW FOR v3.70 ----------------------------------------- -------------------------------------------------- 1.1.1 New .version directive value -------------------------------------------------- The assembler's .version directive now accepts the value "54_ext". This value is used to specify any C54x device (after C548) with extended program space. -------------------------------------------------- 1.1.2 C++ Support -------------------------------------------------- The C54x compiler now supports C++ as defined by Ellis and Stroustroup's "The Annotated C++ Reference Manual" (ARM). The compiler also supports many of the features in the X3J16/WG21 working paper. You can compile C and C++ files in a single command. The compiler uses the conventions for filename extensions to distinguish between the files. NOTE: The compiler does not support C++ with 'C54x far mode. ------------------------------------------------- 1.1.3 Additional Shell Options for C++ ------------------------------------------------- The following options have been added for C++ support: -ep[.]new_extension Sets default extension for C++ source files. -fg Processes a C filename as a C++ file. -fp Identifies filename as a C++ file, regardless of its extension. By default, the compiler treats .C, .cpp, .cc, or .cxx files as C++ files. -pe Enables embedded C++ mode. ------------------------------------------------- 1.1.4 Global C++ Variable Construction ------------------------------------------------- Global C++ variables having constructors and destructors require their constructors to be called during program initialization and their destructors to be called during program termination. The C/C++ compiler produces a table of constructors to be called at startup. The table is contained in a named section called .pinit. The constructors are invoked in the order that they occur in the table. All constructors are called after initialization of global variables and before main() is called. Destructors are registered through the atexit() system call and therefore are invoked during the call to exit(). Format of Initialization Records in the .pinit Section: .pinit section +----------------------+ | addr of constructor 1| +----------------------+ | addr of constructor 2| +----------------------+ | addr of constructor 3| +----------------------+ | ... | +----------------------+ | addr of constructor n| +----------------------+ The -c or -cr linker option causes the linker to combine all of the .pinit sections from all the C/C++ modules and appends a null word to the end of the composite .pinit section. The boot routine knows the end of the global constructor table when it encounters a null constructor address. ------------------------------------------------- 1.1.5 C++ Syntax for Pragmas ------------------------------------------------- For pragmas that apply to functions or symbols, the syntax for the pragmas differs between C and C++. In C, you must supply, as the first argument, the name of the object or function to which you are applying the pragma. In C++, the name is omitted; the pragma applies to the declaration of the object or function that follows it. For example, the syntax of pragma CODE_SECTION for C is: #pragma CODE_SECTION (symbol, "section_name") [;] For C++, the syntax is: #pragma CODE_SECTION ("section_name") [;] ------------------------------------------------- 1.1.6 Generating Linknames ------------------------------------------------- The compiler transforms the names of externally visible identifiers when creating their linknames. The algorithm used depends on the scope within which the identifier is declared. For objects and C functions, an underscore (_) is prefixed to the identifier name. C++ functions are prefixed with an underscore also, but the function name is modified further. Mangling is the process of embedding a function's signature (the number and type of its parameters) into its name. Mangling occurs only in C++ code. The mangling algorithm used closely follows that described in The Annotated Reference Manual (ARM). Mangling allows function overloading, operator overloading, and type-safe linking. For example, the general form of a C++ linkname for a function named func is: __func__Fparmcodes where parmcodes is a sequence of letters that encodes the parameter types of func. For this simple C++ source file: int foo(int i); //global C++ function the resulting assembly code is: __foo_Fi; The linkname of foo is __foo__Fi, indicating that foo is a function that takes a single argument of type int. To aid inspection and debugging, a name demangling utility is provided that demangles names into those found in the original C++ source. -------------------------------------------------- 1.1.7 C++ Name Demangler -------------------------------------------------- The C++ compiler implements function overloading, operator overloading, and type-safe linking by encoding a function's signature in its link-level name. The process of encoding the signature into the linkname is often referred to as name mangling. When you inspect mangled names, such as in assembly files or linker output, it can be difficult to associate a mangled name with its corresponding name in the C++ source code. The C++ name demangler is a debugging aid that translates each mangled name it detects to its original name found in the C++ source code. The syntax for invoking the C++ name demangler is: dem500 [options] [filenames] By default, the C++ name demangler sends output to standard out. You can use the -o file option if you want to send output to a file. The other supported options are: -h Prints a help screen that provides an online summary of the C++ name demangler options -u Specifies that external names do not have a C++ prefix -v Enables verbose mode (outputs a banner) -------------------------------------------------- 1.1.8 Unified Runtime Library -------------------------------------------------- This release of the C54x toolset supports a unified C/C++ runtime library. The library rts.lib can be linked with either C or C++ object files with out recompiling the libraries. -------------------------------------------------- 1.1.9 Known C++ Bugs -------------------------------------------------- - (SDSsq11514) the compiler may generate incorrect code when using -o2 or -o3 on C++ code containing ".*" or "->*" pointer to member operations - (SDSsq11516) long types for bitfields are not supported even though they are legal in C++ - (SDSsq11669) C++ compiler does not allow enumerators larger than type 'int' - (SDSsq11710) covariant return types of virtual functions are not fully supported - (SDSsq11721) 'extern inline' function are not supported - (SDSsq11742) std::type_info::operator==() may return FALSE for equivalent fundamental or derived types when typedefs for them are used ----------------------------------------- SECTION 1.2 Support for Profiling ----------------------------------------- The shell now supports the -gp option. This option sets line directives at the beginning and end of all functions so that function level profiling is possible. The line directives do not inhibit optimization and will not be removed because of optimization. This option will also place line directives around loops. A line directive will be set at: - the opening brace (or statement) to stop at the beginning of a loop iteration. - the closing brace to stop at the end of a loop iteration. If the compiler can determine that the loop has a pre-header block, it will also set a line directive at the control statement (for, while, do) to stop before the loop (but not before each loop iteration). ----------------------------------------- SECTION 1.3 Additional Shell Options ----------------------------------------- Note: When using an option with a parameter, the parameter must be located immediately next to the option (no space). -oisize Sets automatic inlining size (-o3 only). If 'size' is not specified, the default is 1. -ac Makes case insignificant in assembly source files -gw Dwarf debug - Additional debugger support -fb absolute listing directory -ff listing/xref file directory -adNAME pre-define NAME for assembler -auNAME undefine NAME for assembler Parser options: -p -pi ignore inline keyword -pl output raw listing to -pr relaxed (non-strict ANSI) -ps strict ANSI mode (errors) -px output xref listing to Parser preprocessing options: -pp -ppa continue with compilation -ppc preprocess only w/comments -ppd dependencies only -ppi file inclusion only -ppl preprocess only w/line # -ppo preprocess only Parser diagnostics options: -pd -pdel set error limit to -pden emit diagnostics ids (for use with -pds#) -pdf output diagnostic to .err file -pdr issue remarks -pds suppress diagnostic -pdse treat diagnostic as error -pdsr treat diagnostic as remark -pdsw treat diagnostic as warning -pdv verbose diagnostics -pdw suppress warnings ------------------------------------------------- SECTION 1.4 Shell Options No Longer Supported ------------------------------------------------- -x Use -pi to disable keyword inlining and guarded inlining; use -oi0 to turn off automatic inlining -ga write out unref'd externs -pe 'E' errors are warnings -pf generate prototype file -pg enable trigraph expansion -pl generate .pp file -pn no #line directives -po preprocess only -pr generate error listing -pwN warning level N -px for -pm, name output file -tf relax prototype checking -tp relax pointer combinations ------------------------------------------- SECTION 1.5 Updated Shell Option (-pk) ------------------------------------------- -pk source files must be strict K&R C. The parser will not accept ANSI C source code with the -pk option. --------------------------------------------------- SECTION 1.6 Using Inline Function Expansion --------------------------------------------------- When an inline function is called, the C source code for the function is inserted at the point of the call. This is known as inline function expansion. Inline function expansion is advantageous in short functions for the following reasons: o It saves the overhead of a function call. o Once inlined, the optimizer is free to optimize the function in context with the surrounding code. --- Note: Function Inlining Can Greatly Increase Code Size Expanding functions inline increases code size, especially inlining a function that is called in a number of places. Function inlining is optimal for functions that are called only from a small number of places and for small functions. --- Inlining Intrisic Operators --------------------------- There are many intrinsic operators for the 'C54x. All of them are automatically inlined by the compiler. The inlining happens automatically whether or not you use the optimizer. Automatic Inlining ------------------ Automatic inline function expansion is performed on small functions when the -o3 option is used. Unguarded Definition-Controlled Inlining ---------------------------------------- The inline keyword specifies that a function is expanded inline at the point at which it is called rather than by using standard calling procedures. The compiler will perform inline expansion of functions declared with the inline keyword. You must invoke the optimizer with any -o option (-o0, -o1, -o2, or -o3) to turn on definition-controlled inlining. Note that automatic inlining is also turned on when using -o3. The -pi option turns off definition-controlled inlining. This option is useful when you need a certain level of optimization but do not want definition-controlled inlining. The following example shows usage of the inline keyword, where the function call will be "replaced" by the code in the called function. inline int volume_sphere(float r) { return 4.0/3.0 * PI * r * r * r; } int foo(...) { ... volume = volume_sphere(radius); ... } Guarded Inlining and the _INLINE Preprocessor Symbol ---------------------------------------------------- When declaring a function in a header file as static inline, additional procedures should be followed to avoid a potential code size increase when inlining is turned off with -pn or the optimizer is not run. In order to prevent a static inline function in a header file from causing an increase in code size when inlining gets turned off, use the following procedure. This will allow external-linkage when inlining is turned off; thus, only one function definition will exist throughout the object files. o Prototype a static inline version of the function. Then, prototype an alternative, non-static, externally-linked version of the function. Conditionally preprocess these two prototypes with the _INLINE preprocessor symbol, as shown below. o Create an identical version of the function definition in a .c file, Inlining Restrictions --------------------- There are several restrictions on what functions can be inlined for both automatic inlining and definition-controlled inlining. Functions with local static variables or a variable number of arguments are not inlined, with the exception of functions decalred as static inline. In functions decalred as static inline, expansion occurs despite the presence of local static variables. In addition, a limit is placed on the depth of inlining for recursive or nonleaf functions. Furthermore, inlining should be used for small functions or functions that are called in a few places (though the compiler does not enforce this). A function may be disqualified from inlining if it: o returns a struct or union o has a struct or union parameter o has a volatile parameter o has a variable length argument list o declares a struct, union, or enum type o contains a static variable o contains a volatile variable o is recursive o contains a pragma o has too large of a stack (too many local variables) Automatic Inline Expansion (-oi Option) --------------------------------------- The optimizer automatically inlines small functions when it is invoked with the -o3 option. A command-line option, -oi/size/, specifies a size threshold. Any function larger than the size threshold will not be automatically inlined. You can use the -oi/size/ option in the following ways: o If you set the /size/ parameter to 0 (-oi0), automatic inline expansion is disabled. o If you set the /size/ parameter to a nonzero integer, the compiler will use this size threshold as a limit to the size of the functions it automatically inlines. The optimizer multiplies the number of times the function is inlined (plus 1 if the function is externally visible and its declaration cannot be safely removed) by the size of the function. The compiler inlines the function only if the result is less than the /size/ parameter. The compiler measures the size of a function in arbitrary units; however, the optimizer information file (created with the -on1 or -on2 option) reports the size of each function in the same units that the -oi option uses. The -oi/size/ option controls only the inlining of functions that are not explicitly declared as inline. If you do not use the -oi/size/ option, the optimizer inlines very small functions. ---------------------------------------------------------------------------- NOTE: -o3 Optimization and Inlining In order to turn on automatic inlining, it is necessary to use the -o3 option. Note that -o3 turns on other optimizations. If you desire the -o3 optimizations, but not automatic inlining, use -oi0 with the -o3 option. ---------------------------------------------------------------------------- ------------------------------------------------------------------------- ... ...

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：