SPACE 2

home *** CD-ROM | disk | FTP | other *** search

/ SPACE 2 / SPACE - Library 2 - Volume 1.iso / program / 330 / doc / sozobon.doc < prev

Wrap

Text File | 1988-10-22 | 46.6 KB | 1,682 lines

The Sozobon C Compiler a freeware offering from Sozobon, Limited Tony Andrews Johann Ruegg Joe Treat User Reference 10/22/88 1. Introduction The Sozobon C Compiler is a complete implementation of the C language as defined by Kernighan & Ritchie and prevailing practice. The package includes a compiler, optimizer, assembler, and linker, as well as several other associated utilities. For runtime library support, version 1.2 of the public domain dLibs routines are used. Like the dLibs package, source code and executables for all components of the Sozobon compiler may be freely distributed. This document describes the various components of the system in detail. Chapter 8 contains a convenient command reference for the various utilities included in the system. Dale Schumacher's documentation for the dLibs package is provided separately. 1.1 System Overview 1.1.1 History The Sozobon compiler was originally written as a replacement front-end for the buggy Alcyon compiler. Johann had been working on the compiler for quite a while, and eventually got the rest of us interested in working on the other parts of the system. I (Tony) started working on an optimizer, mainly because I hadn't written one before and it sounded like fun. As - 1 - Sozobon C Compiler User Reference the pieces started coming together, we discovered that there weren't any public domain assemblers that generated Alcyon-compatible objects. Joe offered to write one, filling the last major hole in the project. 1.1.2 Distribution The Sozobon C Compiler is distributed in both binary and source form. The programs and code are copyrighted, but may be freely distributed. The only restrictions are: 1. No charge may be made other than reasonable charges for reproduction. 2. Modified versions must be clearly marked as such. 3. The authors are not responsible for any harmful consequences of using this software, even if they result from defects in it. You are encouraged to make copies for friends, upload it to bulletin boards, or distribute it via networks. This is not a shareware product. We wrote this compiler because it was fun, not because we expected to make any money from it. 1.1.3 Obtaining the Source Code If you received only a binary release of the compiler (or if your binary release is incomplete or outdated), the complete source distribution can be obtained by sending $10 to: Tony Andrews 5902E Gunbarrel Ave. Boulder, CO 80301 Be sure to include your return address, and specify single or double-sided floppies. Checks should be payable to "Tony Andrews". Feel free to split the cost with as many people as you want. We're interested in getting the compiler distributed and used, not in spending our spare time writing floppies. The complete release comes on two single-sided floppies or one double-sided floppy containing: * all executables * source code for the compiler * source code for the utilities * documentation - 2 - Sozobon C Compiler User Reference * dLibs, version 1.2 (including source) Most of this will be in arc format to conserve space. Since the compiler can compile itself, you will have everything you need to hack on any part of the package. 1.1.4 Performance The compiler runs faster than Alcyon and generates code that is generally better than Alcyon's. The Alcyon compiler is smarter about register allocation and usage, but the Sozobon optimizer makes up most of the difference. Our assembler is better at generating short forms of the branch instructions, so that helps too. The code generation appears to be quite solid. None of the problems that we found during beta testing involved the code generation of the compiler, optimizer, or assembler. 1.2 Acknowledgements We'd like to thank our beta testers for their help in completing this project. Ian Lepore, in Denver, was the first to dive in and start using the compiler, and made many helpful suggestions. Dale Schumacher worked long hours to get a new release of dLibs ready and pointed out several problems. And Steve Yelvington was the first to develop a GEM application using the Sozobon compiler. 1.3 Support We're interested in receiving bug reports from people using the compiler. We use this software every day, so we have a strong interest in making sure it works right. Feel free to mail us bug reports at the address listed above. We can also be reached at the following electronic addresses: UUCP: onecom!wldrdg!tony Citadel: Tony Andrews @ FWBBS Bugs will be assigned priorities based roughly on the following scale: 1. Bug reports with a fix included. If you give us the fix, it will almost certainly show up in the next release. You've got the source; don't be afraid to use it. 2. Bug reports with a good description of the problem, the environment in which it occurred, and a SMALL program that reproduces the problem. - 3 - Sozobon C Compiler User Reference 3. All others. Please try to at least isolate the problem to a small, repeatable example program. If you can find the bug and fix it, that's wonderful, but at least give us enough infomation to duplicate the bug ourselves. 2. Development Environment This section describes in more detail the operation of the compiler and the relationship between parts of the compiler and the corresponding pieces of the Alcyon compiler. The compiler works best when used with a shell like 'gulam'. There is currently little support for GEM, either in the runtime libraries, or in the commands themselves. None of the commands pause before exiting, yet. Since none of us use GEM, we don't have a very good perspective on how a GEM user would want things to work. If you've used the Alcyon compiler with GEM, you should have no trouble creating appropriate batch files for the Sozobon compiler. The compiler should be usable on machines with 512K and a single disk. This document doesn't describe the optimal layout for various ST configurations, but you can probably figure out what makes the most sense for your machine. This will probably involve a ram disk, and some arrangement of programs and libraries on one or more floppies. 2.1 Environment Variables Several environment variables may be used to alter the operation of the compiler. The variables are used to specify the location of executables, header files, libraries, and temporary files. Each variable may reference a list of directories to be searched, with elements of the list separated by commas or semicolons. The variables are: PATH executables INCLUDE header files LIB startup code and libraries TMP temporary files The "TMP" variable is currently only used by 'cc' to construct the object file list given to the loader. Reasonable defaults are assumed if these variables aren't set. The specific defaults are described later in the command references. - 4 - Sozobon C Compiler User Reference 2.2 Machine Dependencies The supported data types and their sizes (in bytes) are: char 1 short 2 int 2 long 4 unsigned char 1 unsigned short 2 unsigned int 2 unsigned long 4 float 4 double 4 POINTER 4 Floating point is supported using the "Fast Floating Point" representation documented by Motorola and implemented by the Alcyon compiler. Both 'float' and 'double' types are supported, but are actually identical. We'd like to support the IEEE format eventually, but this will have to do for now. Any of the basic data types may be declared as register variables. Pointers occupy the A registers, all other types are placed in D registers. Five data registers and three address registers are available for use by register variables. 2.3 Compiler Limits Some limits imposed by the Sozobon compiler are: * Strings are limited to 256 characters in length * Local variables are limited to a total of 32K in size per function. * The size of a single structure may not exceed 32K. * Include files may not be nested more than 8 deep. * The assembler will have problems with extremely large source files that produce more than 32K of code from a single file. * Identifiers internal to a file may be of any length. * Only the first 7 characters of external identifiers are significant, and case is significant for all identifiers. - 5 - Sozobon C Compiler User Reference 2.4 Relationship to the Alcyon Compiler The components of the Sozobon compiler were developed by replacing pieces of the Alcyon compiler one by one. For this reason, a certain level of compatibility with the Alcyon system was inevitable. While the Alcyon system provided a convenient way to bootstrap a new compiler, our goal was not to be completely compatible with Alcyon. Compatibility is more in the interfaces between pieces of the compiler than in their command line options. The Sozobon compiler program replaces the pre-processor and the two compiler passes of the Alcyon system. This speeds up compilation quite a bit. The output of the compiler is suitable for input to other compatible assemblers such as Alcyon's assembler or the MadMac assembler. The optimizer is tuned in many ways to the output of the Sozobon compiler and could not (without some modifications) be used with the Alcyon compiler, or with hand-written assembly code. The Sozobon assembler was developed primarily to accept input from the Sozobon compiler (or optimizer) and doesn't support all the features of the Alcyon or MadMac assemblers. It does generate compatible object files, though, and generates smaller code since it uses 'short' branch instructions wherever possible. The Sozobon loader accepts Alcyon object files and libraries. The function of the 'relmod' program is incorporated into the loader, so a separate utility isn't needed. The other Sozobon utilities all operate on and generate Alcyon-compatible object files and libraries. 3. Component Overviews The following sections describe in detail the passes of the compiler. 3.1 Compiler The compiler is essentially compatible with the Alcyon compiler, but is stricter about type checking and will complain about things that Alcyon permits. The compiler implements the full C language as described by K&R, with the usual extensions: * bit fields * enumerations - 6 - Sozobon C Compiler User Reference * structure assignment * structure parameters * structure return values * assembly escapes Most of the features listed above are self-explanatory. Assembly code can be embedded within C using the following syntax: asm("assembly code"); The string within quotes is passed directly to the output file. It is preceded by a tab, and followed by a newline, so these don't need to be given in the string. Extreme caution should be used when running the optimizer on C code that contains assembly escapes. The compiler has been tested with the "C Compiler Torture Test" from the Austin Code Works. This tests for full K&R compatibility. The compiler has been used to compile itself as well as many other programs totaling around 50,000 lines of code. The compiler uses the "normal" 68000 C calling conventions. Register A6 is used as a frame pointer, and function return values are placed in D0. Registers D3-D7 and A3-A5 are used to hold register variables. 3.2 Optimizer The Sozobon optimizer accepts assembly language input from the compiler and generates optimized assembly output. The optimizer is tuned to the output of the compiler and should not be used with hand-written assembly code. The optimizer performs several kinds of optimizations. Command line options can be used to control which kinds of operations are performed on the source file. The most important function of the optimizer is branch optimization. The compiler's code generation can be simplified somewhat if an optimizer is used to clean up redundant branches. Because branch optimization lays the foundation for everything else the optimizer does, this cannot be disabled on the command line. The other major part of the optimizer performs peephole optimization replacing specific instruction sequences with shorter or faster ones. From one to three instructions are re-written. The optimizer is able to ignore instructions that - 7 - Sozobon C Compiler User Reference don't affect the validity of the optimization, so the instructions aren't necessarily adjacent. This process is aided by the use of dataflow analysis, which determines which registers are "live" at each point in a function. This part of the optimizer is more bug-prone, and can be disabled without affecting branch optimization. The current optimizer is only a start; the dataflow analysis lays the groundwork for many more peephole optimizations. The optimizer appears to be quite solid, and its use is highly recommended. The compiler depends pretty much on the optimizer to clean up useless branches, and this helps keep the compiler's code generation simple. 3.3 Assembler The assembler was designed to support the compiler and optimizer. It's small (about half the size of the Alcyon assembler) and quite a bit faster. If you want a "user-friendly" assembler, you're probably better off looking elsewhere, or hacking the features you want into our assembler yourself. Besides being smaller and faster, the Sozobon assembler does a better job of optimizing branch instruction sizes. 3.4 Linker The linker accepts Alcyon-compatible object files and libraries. It incorporates the function of the Alcyon 'relmod' program, so a separate utility is not needed. The linker can be instructed to make multiple passes over libraries if their contents are not ordered by dependency. 3.5 Utilities Besides the primary programs, there are several useful utilities provided. * The 'cc' program is used to run the passes of the compiler, avoiding the use of batch files. * The 'nm' program dumps the symbol table of object files, libraries, and executables. * The 'size' utility prints the size of text, data, and bss for objects, libraries, and executables. * The 'ar' program manages libraries of object modules. * The 'globs' program isn't very useful unless you have the Alcyon compiler. It removes local symbols from object - 8 - Sozobon C Compiler User Reference modules and libraries. These aren't needed for linking and take up quite a bit of space. If you have Alcyon libraries that you use frequently, 'globs' can reduce their size by around 30%. * An enhanced version of a public-domain 'make' utility is provided and documented in a separate file. 3.6 Library The dLibs routines, written by Dale Schumacher provide runtime support for the Sozobon compiler. We started our development using dLibs version 1.1, but worked closely with Dale as he prepared his 1.2 release to insure full compatibility with our programs. The new release is fully compatible with our compiler. 3.6.1 Startup Code The dLibs C startup code is used to link programs. 3.6.2 C Runtime Library The dLibs documentation is included in our release, since there are no changes for use with the Sozobon compiler. 3.6.3 Floating Point Library Our floating point code is included as a separate library. One traditional problem with C compilers and floating point is that as soon as you call printf(), you wind up linking in a bunch of floating point code whether you need it or not. To avoid this problem the dLibs package and our floating point library actually contain (slightly) different versions of printf and scanf. The versions in the normal library contain no support for floating point. The versions in the floating point library do support floating point. If the "-f" option is passed to "cc", the printf and scanf routines are taken from the floating point library. Otherwise, the versions in the normal library are used, and no floating point code gets linked at all, unless required by other parts of your program. We make no claims regarding the accuracy or speed of the floating point code. This code was thrown together to get something into this release, but still needs plenty of work. Only the basic operations are supported. Those of you with the Alcyon compiler can use the fast floating point library (libf) in place of our routines. Low level conversion routines between ASCII and floating point numbers are - 9 - Sozobon C Compiler User Reference available in libf, or printf and scanf can be used by linking with the entire Alcyon runtime library. - 10 - Sozobon C Compiler User Reference 4. Known Shortcomings and Bugs The floating point code needs more work. Unfortunately, this code isn't much fun to work on, and since none of us have much use for floating point, it probably won't receive much attention. If anyone has access to a public domain floating point library (IEEE preferred), we'd be happy to look into it for a future release. More optimization work is needed and many error cases could be handled better. 5. Next Release Plans Several items are high on the wish list for the next release. * A port of the compiler to Minix-ST is already underway. The Minix operating system comes with source code for everything except the C compiler, so the Sozobon compiler fills a void there and already contains some features (e.g. bit fields, floating point) absent in the Minix C compiler. * The assembly code produced by the compiler should refer to parameters and locals symbolically. This will make it easier to use embedded assembly within C. * Execution profiling is already well underway. This will be an option that adds instrumentation to the generated code to measure the number of calls made to each routine, and to approximate the amount of time spent in each part of the program. This can be extremely useful when trying to improve the performance of a working program. 6. Future Directions The compiler is quite usable and has already replaced Alcyon and Megamax as our standard development environment. Over time, we plan to move toward ANSI conformance. This is a very large task, impacting the runtime library as well as the compiler itself. Other possible projects: * Dale Shumacher has already done some work on a debugger, so with some more work, that would be a nice addition to a future release. * A port to the Amiga. * A version for the 8086. - 11 - Sozobon C Compiler User Reference 7. Summary We've had fun creating this compiler. While we've been using this software for a long time ourselves, a lot of additional work went into making a release to the general public. That effort will have been well-spent if it encourages more people like us to continue developing software for the ST or if it helps more people learn C who might not have otherwise. May the source be with you... Tony Andrews Johann Ruegg Joe Treat - 12 - Sozobon C Compiler User Reference 8. Command References 8.1 cc C Compiler driver program 8.1.1 Synopsis cc [ options ] file [ file ... ] 8.1.2 Description The cc command runs the passes of the compiler as needed to process files given on the command line. Various options exist to control the execution of cc or the compiler passes it runs. Cc recognizes file names with the following suffixes: .c C source file .s Assembly language input .o Relocatable object module .lib Library module (.a is also recognized) Normally, cc tries to form an executable image using the files given on the command line. C source files are compiled and assembled; assembly language files are passed to the assembler, and the resulting object modules are linked with any other object files or libraries given to form an executable program. The name of the executable is based on the first file name seen on the command line. If the first file name was "foobar.c", the executable would be named "foobar.ttp". The following options to the cc command may be used to alter the default operation just described: -c Supress the link phase. Leave generated object modules around. -O Run the assembly optimizer between the compiler and assembler. -S Compile C source files leaving the assembly language output in the corresponding ".s" file. -Ipath Include 'path' in the list of directories to be - 13 - Sozobon C Compiler User Reference searched for header files (e.g. "-I\usr\include"). -Dname -Dname=value Define the pre-processor macro 'name'. If no value is given the macro is defined as 1. -Uname Un-define one of the built-in macros. For a list of the built-in macros, see the 'hcc' reference section. -o file Put the generated executable in the named file. -f Include the floating point library when linking. -m Generate a load map during the link phase. -t Put a symbol table in the generated program. -v Show the passes as they are being executed, and the version of 'cc'. -n Like -v, but don't really execute anything. -p This option enables runtime execution profiling. The compiler generates some additional code to count the number of calls to each function. Also, different startup code and runtime libraries are used. This option isn't fully supported yet. It's presence here will allow us to upgrade to support profiling without having to replace 'cc' and 'hcc'. 8.1.3 Files Cc assumes that header files, libraries, and executables can be found in the following locations: Primary location Alternate ------------------------------------------------- header files \sozobon\include \include libraries \sozobon\lib \lib executables \sozobon\bin \bin - 14 - Sozobon C Compiler User Reference In addition to the above locations, cc also checks the root directory of the current drive as well as the current directory. If you're running a command line interpreter like 'gulam' or the Beckemeyer C Shell, environment variables can be used to override the default locations listed above. The variables "INCLUDE", "LIB", and "PATH" may contain lists of paths separated by commas or semicolons. The given paths will be searched, in order, instead of the primary and alternate paths shown above. - 15 - Sozobon C Compiler User Reference 8.2 hcc Hans' C compiler 8.2.1 Synopsis hcc [ options ] file [ file ... ] 8.2.2 Description The hcc command accepts C source files and generates assembly language output to the corresponding ".s" files. The pre-processor and all phases of the compiler are included within this program. The following options are accepted by hcc: -Ipath Include 'path' in the list of directories to be searched for header files (e.g. "-I\usr\include"). -Dname -Dname=value Define the pre-processor macro 'name'. If no value is given the macro is defined as 1. -Uname Un-define one of the built-in macros. -V Display version information. -P Instructs the compiler to generate modified function entry code that will count the number of calls to each function. This is not fully implemented, but is provided for compatibility with a future release of the compiler. Directories listed in the "INCLUDE" environment variable are added to the list of standard locations to check for header files. Several macros are normally pre-defined. These are: MC68000, mc68000, SOZOBON, ATARI_ST, and (as applicable) TOS or MINIX. - 16 - Sozobon C Compiler User Reference 8.3 top Tony's optimizer. 8.3.1 Synopsis top [ -vpbfd ] infile [ outfile ] 8.3.2 Description Top is an assembly-code optimizer designed for use with hcc. It accepts as input, the code generated by hcc and generates an optimized form of the assembly as output. If 'outfile' is given, the optimized code is written to the named file. If no output file is listed, the optimized code replaces the original code in the input file. Using the name "-" for the output file causes the output to be sent directly to the screen. The optimizer is normally run by the cc command, but accepts the following options when run manually: -v Display statistics about optimizations made on the file, and the version information for 'top'. -p Disable peephole optimizations. -b Disable conditional branch reversals. -f Disable data-flow analysis (live-dead register analysis) and any optimizations depending on it. -d Print detailed debugging information to stderr. The optimizer performs branch optimization as a minimum. The options above can be used to disable everything else. The optimizer will sometimes reverse the sense of a conditional branch to produce shorter code; this is disabled by the -b options. Data-flow analysis determines which machine registers contain useful data at any point in the code. This is used by other parts of the optimizer, but is also a likely source of bugs. It can be disabled with -f. - 17 - Sozobon C Compiler User Reference Peephole optimizations are performed by looking at from one to three instructions at a time to see if a better sequence can be used. Optimizations of this kind are disabled with -p. If a bug is found in the optimizer, the options -bfp can be used together to eliminate more advanced features while still gaining the benefit of the more reliable (and quite useful) branch optimizer. - 18 - Sozobon C Compiler User Reference 8.4 jas Joe's assembler. 8.4.1 Synopsis jas [ -NVlu ] [ -s dir ] [ -Ln ] [ -o file ] file 8.4.2 Description The jas assembler is designed for compatibility with the Alcyon assembler. It doesn't provide many features the assembly language programmer might want, but is intended more for use by a compiler front-end. Jas generally produces smaller code than the Alcyon assembler because it is smarter about generating short branch instructions. Also, jas uses no temporary files and runs quite a bit faster than Alcyon. Some of the command line options are accepted for compatibility with the Alcyon assembler, but are actually ignored. The following command line options are supported: -N Don't generate 'short' branch instructions. -V Print a version message. -l -u -s dir Ignored. -Ln By default, no local symbols are placed in the symbol table of the output. This option instructs jas to put all symbols into the symbol table if n is 2 or greater. If the option '-L1' is given, symbols whose name doesn't start with 'L' are written to the symbol table. -o file Be default, the assembler replaces the '.s' file extension of the input file with '.o' to form the name of the output. This option can be used to write the output to any file. - 19 - Sozobon C Compiler User Reference 8.5 ld Loader 8.5.1 Synopsis ld [ -mvnbp ] [ -f file ] [ -o output ] [ -u symbol ] ... file ... 8.5.2 Description The ld command links object modules and libraries to form an executable program. Both object modules and libraries may be passed to ld for linking. Several options may be specified to alter the operation of the loader: -m Generate a load map -t Put a symbol table in the output file. -p Make multiple passes over each library until no more references can be satisfied. If libraries are ordered appropriately, this option is not needed and linking will be faster. -b This option can be used when linking large programs to reduce the amount of memory used by the loader. The loader makes more disk accesses when this option is used. -f file This option is useful when many files are to be linked. The loader reads the file name specified for a list of object modules and libraries to be linked. Names in the file should be separated by white space or newlines. -o file By default, the name of the executable file created is based on the first file name given on the command line. An initial file name of "foobar.o" would result in a program named "foobar.ttp". This option allows a different name to be specified. -u symbol The given symbol is marked as undefined. This can be useful when linking from libraries. A symbol (e.g. - 20 - Sozobon C Compiler User Reference _main) can be marked as undefined to force loading from the library. -v Tells the loader to be verbose about what it's doing, and print version information. - 21 - Sozobon C Compiler User Reference 8.6 size Prints program sizes 8.6.1 Synopsis size [ -oxV ] file ... 8.6.2 Description The size command examines object modules or libraries and prints information about their size. By default, for each module (or member of a library), the size of the text, data, and bss sections are printed in decimal. The 'o' and 'x' options can be used to print the sizes in octal or hexadecimal respectively. If the 'V' option is given, the version number of 'size' is printed. - 22 - Sozobon C Compiler User Reference 8.7 nm Prints symbol tables 8.7.1 Synopsis nm [ -g ] file ... 8.7.2 Description The nm command dumps the symbol table of all object files, libraries or executables given on the command line. If the 'g' option is given, only information about global symbols is printed. - 23 - Sozobon C Compiler User Reference 8.8 ar Archive management program 8.8.1 Synopsis ar -{drqtpmx}[vcV] afile [ file ... ] 8.8.2 Description The ar command is used to maintain object module libraries. It can perform one of seven basic operations as selected by a command character. The operation of the selected command can be modified by other option characters that may follow it. The name of the archive to be manipulated follows the option characters. Some commands also require (or allow) the names of files in the archive to follow the archive name on the command line. The following commands are supported. d Delete the named files from the archive. r Replace the named files in the archive. New files are placed at the end of the archive. q Quickly append the named files to the end of the archive. t Print the contents of the archive. If file names are given, only show those files. p Print the named files to the standard output. m Move the named files to the end of the archive. x Extract the named files from the archive, or all files if none were listed on the command line. The following characters modify the operation of the commands described above. v Generally show more information about what ar is - 24 - Sozobon C Compiler User Reference doing. In a table of contents, show information about the size, mode, etc. c Suppress the message normally printed when a new archive is created. V Prints version information. - 25 - Sozobon C Compiler User Reference 8.9 globs Remove non-global symbols 8.9.1 Synopsis globs file ... 8.9.2 Description The named files (object modules or libraries) are compressed by removing non-essential symbols from their symbol table. Since the Sozobon assembler does this by default, this program it mostly useful to users with old Alcyon libraries. - 26 - Table of Contents 1. Introduction ................................. 1 1.1 System Overview ........................... 1 1.1.1 History ............................. 1 1.1.2 Distribution ........................ 2 1.1.3 Obtaining the Source Code .............. 2 1.1.4 Performance ......................... 3 1.2 Acknowledgements ......................... 3 1.3 Support .................................. 3 2. Development Environment ....................... 4 2.1 Environment Variables ..................... 4 2.2 Machine Dependencies ...................... 5 2.3 Compiler Limits ........................... 5 2.4 Relationship to the Alcyon Compiler .......... 6 3. Component Overviews ........................... 6 3.1 Compiler ................................. 6 3.2 Optimizer ................................ 7 3.3 Assembler ................................ 8 3.4 Linker ................................... 8 3.5 Utilities ................................ 8 3.6 Library .................................. 9 3.6.1 Startup Code ......................... 9 3.6.2 C Runtime Library ..................... 9 3.6.3 Floating Point Library ................ 9 4. Known Shortcomings and Bugs ..................... 11 5. Next Release Plans ............................. 11 6. Future Directions ............................. 11 7. Summary ...................................... 12 8. Command References ............................ 13 - I - 8.1 cc ....................................... 13 8.1.1 Synopsis ............................ 13 8.1.2 Description ......................... 13 8.1.3 Files ............................... 14 8.2 hcc ...................................... 16 8.2.1 Synopsis ............................ 16 8.2.2 Description ......................... 16 8.3 top ...................................... 17 8.3.1 Synopsis ............................ 17 8.3.2 Description ......................... 17 8.4 jas ...................................... 19 8.4.1 Synopsis ............................ 19 8.4.2 Description ......................... 19 8.5 ld ....................................... 20 8.5.1 Synopsis ............................ 20 8.5.2 Description ......................... 20 8.6 size ..................................... 22 8.6.1 Synopsis ............................ 22 8.6.2 Description ......................... 22 8.7 nm ....................................... 23 8.7.1 Synopsis ............................ 23 8.7.2 Description ......................... 23 8.8 ar ....................................... 24 8.8.1 Synopsis ............................ 24 8.8.2 Description ......................... 24 8.9 globs .................................... 26 8.9.1 Synopsis ............................ 26 8.9.2 Description ......................... 26 - II -