Amiga ISO Collection

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

/ Amiga ISO Collection / AmigaUtilCD2.iso / Programming / C / BC_DICE3.DMS / in.adf / DOC / dice_commands.doc < prev next >

Wrap

Text File | 1995-01-09 | 67.2 KB | 1,695 lines

dice/CommandSummary dice/CommandSummary * = Included in MiniDice Command : Purpose ===========+========================================================= ame : Advanced MicroEmacs text editor. -----------+--------------------------------------------------------- bintohex : Convert binary files to Motorola S-records or Intel Hex : Dumps. Used for programming ROM chips. -----------+--------------------------------------------------------- cat : Shows contents of text files (takes wild cards) -----------+--------------------------------------------------------- ci : Check in RCS Source (RCS). -----------+--------------------------------------------------------- co : Check out RCS Source (RCS). -----------+--------------------------------------------------------- *das : DICE Assembler. -----------+--------------------------------------------------------- *dc1 : DICE Compiler. -----------+--------------------------------------------------------- *dcc : DICE Compiler Front End. -----------+--------------------------------------------------------- *dcpp : DICE Preprocessor. -----------+--------------------------------------------------------- dd : DICE Debugger. -----------+--------------------------------------------------------- *DICEHelp : Fast online help utility. Integrates with any editor. -----------+--------------------------------------------------------- diff, : File compare utility, three-way file compare utility diff3 : (RCS). -----------+--------------------------------------------------------- *dlink : DICE Linker. -----------+--------------------------------------------------------- *dmake : DICE Make Utility. Automates compiles. -----------+--------------------------------------------------------- *dme : Text editor. -----------+--------------------------------------------------------- dobj : Disassembles object & executable files. -----------+--------------------------------------------------------- dprof : Code profiler. Helps optimize code for speed. -----------+--------------------------------------------------------- dsearch : Search for a string in a File. -----------+--------------------------------------------------------- du : Determine Disk space Usage. -----------+--------------------------------------------------------- dupdate : Distribution Maker. -----------+--------------------------------------------------------- expand : Expand Wild cards to stdout with formatting. -----------+--------------------------------------------------------- fdtolib : Creates Link Libraries from standard .FD files. -----------+--------------------------------------------------------- fdtopragma : Converts standard .FD files into -----------+--------------------------------------------------------- flush : Flush libraries, etc. out of memory. -----------+--------------------------------------------------------- head : Display first few lines of a file. -----------+--------------------------------------------------------- hunks : Show internal structure of object or executable files. -----------+--------------------------------------------------------- ident : Identify files (RCS). -----------+--------------------------------------------------------- istrip : Strip Comments from include files. -----------+--------------------------------------------------------- lbmake : Link Library Creation Utility. -----------+--------------------------------------------------------- libtos : Convert Large-Data Amiga.lib to Small-Data version. -----------+--------------------------------------------------------- loadabs : For creating ROM images located at a specific address. -----------+--------------------------------------------------------- loadfile : Load & hold a file in memory. -----------+--------------------------------------------------------- *makeindex : Create an index file for use by DICEHelp. -----------+--------------------------------------------------------- *makeproto : Create a file containing function prototypes for your : code. -----------+--------------------------------------------------------- merge : Three Way File Merge (RCS). -----------+--------------------------------------------------------- rcs : Change RCS File Attributes (RCS). -----------+--------------------------------------------------------- rcsclean : Clean up RCS Working Files (RCS). -----------+--------------------------------------------------------- rcsdiff : Compare RCS Revisions (RCS). -----------+--------------------------------------------------------- rcsmerge : Merge RCS Revisions (RCS). -----------+--------------------------------------------------------- rlog : Display RCS History (RCS). -----------+--------------------------------------------------------- romable : Generate romable image. -----------+--------------------------------------------------------- touch : Update a file's datestamp without changing the file. -----------+--------------------------------------------------------- ttxsame : Used by integrated error scripts to start TurboText. -----------+--------------------------------------------------------- *VMake : Visual Make program. A front-end for the compiler. -----------+--------------------------------------------------------- *VOpts : Visual Options. Usually invoked from within VMake. -----------+--------------------------------------------------------- *wbrun : Used to simulate starting a program from Workbench. -----------+--------------------------------------------------------- wc : Count words, lines, etc. in a file. -----------+--------------------------------------------------------- dice/das dice/das FUNCTION DICE Assembler SYNOPSIS DAS asmfile [-o objectfile] [-E errorfile] [-nu] DESCRIPTION Das is a minimal 68000 assembler designed to assemble the output of dc1. || NOTE: Das should not be used for assembly projects, it is meant || solely to deal with the output from the compiler. Das supports || only a minimal subset of features. -o objfile Specify object file, else writes to asmfile.o. -E errorfile Specify file for errors, else diagnostics are sent to stderr. -nu Specify that HUNK_UNIT hunks have no name. This option is used for creating link libraries, to make the library smaller) SEE ALSO Chapter . dice/dc1 dice/dc1 FUNCTION DICE Compiler SYNOPSIS DC1 cppd_src_file [-o outfile] options DESCRIPTION DC1 is the compiler itself. As input it requires a file preprocessed by dcpp, and as output it provides assembly code ready for the das assembler. Normally one uses either dcc or VMake as a front end, never directly invoking dc1. The compiler generates absolute-data references and absolute code references by default. Do not confuse this with DCC's default, which is small-data and small-code. The compiler will put argument and auto variables into registers according to register availability and usage. It will use A0-A1/D0-D1 for register variables whenever possible. Consequently, the most heavily used variables will be in registers even for very large subroutines. You should get into the habit of declaring automatic variables within sub blocks rather than declaring all your autos at the top of the procedure. Apart from making the code more modular, this will enable the compiler to make better decisions when allocating register variables. DCC does not do any major contents tracking and redundant instructions will be generated. DAS will handle properly optimizing branches and DAS has a peephole optimizer built in it to handle other obvious redundancies. The compiler does some optimizations itself, such as using bit instructions to handle special cases of &, |, and ^, include using BTST. || NOTE: volatile forces a data item NOT to be placed in a register. || register is treated as a hint only by the compiler. const is || ignored by default but will force objects into the code section || given the -ms or -mS options (see below). Other type and storage || qualifiers are described in chapter . -S -S0 Set alternate section names "libdata" and "libbss". -Sd name Set section name for data sections -Sb name Set section name for bss sections -Sc name Set section name for code sections -SD name Set section name for __far data sections -SB name Set section name for __far bss sections The -S option allows you to modify the default section naming conventions. DICE uses data, text, and bss as defaults for the data, code, and bss sections. The DICE c.lib is compiled with -S and the startup code (c.o) references these first to force c.lib's data to come before program data. The data ordering is then as follows: 1) Library Initialized Data 2) Program Initialized Data 3) Library BSS Space 4) Program BSS Space As long as the program does not declare more than 64KBytes of initialized data it can be linked with the small-data model c.lib. Thus, large-data-model programs that declare more than 64KBytes of BSS space will still link with the small-data-model c.lib This may be of no consequence because any __far declared data will be placed in a different data segment entirely. Simply declare your large arrays as __far and the rest may remain small-data -d[#] Set debug mode. This isn't pretty, it is primarily used for diagnosing potential compiler problems. -E file specify stderr file, any errors are appended to the file instead of to stdout. Useful for batch compiles -R Tells the compile to remove (delete) the input file when it no longer needs it. The input file is usually a temporary preprocessor file and DCC will use this option to get DC1 to delete it as soon as possible. -proto The main compiler will generate errors for any unprototyped function call. -r Resident option. The main compiler will generate special autoinit code to initialize data-data relocations. This simplifies the work that DLink and the startup module must do to support residentable programs. -v Verbose -o outfile Specify assembly output file name -mc Small-code model (DCC default) -mC Large-code model (DC1 default) -md Small-data model (DCC default) -mD Large-data model (DC1 default) -mw Absolute-word addressing (overrides -md/-mD) -ma Absolute addressing (no effect on DC1 operation) These options specify the memory model. The small-code model uses PC-relative addressing and the small-data model uses A4-relative addressing -mw is used when making ROMable code and specifies that the ABSOLUTE WORD addressing mode be used instead of either absolute long or A4-relative. Absolute word addresses are resolved at link time. || NOTE: This option should not be used when generating || executables meant to run on the Amiga. -ms0 (default) const is ignored -ms string constants and const objs placed in code section -mS string constants and const objs placed in code section These options control how const data items are handled, including string constants such as char *ptr = "abcd"; The default is to ignore the const type qualifier. If -ms is specified string constants and const data items are placed in the code section. Local references to const data items use PC-RELATIVE addressing. Remote references (from other modules) to const data items use ABSOLUTE LONG addressing. -mS works the same as -ms but remote references are forced to use PC-RELATIVE addressing. || NOTE: This can be dangerous and the final CODE size MUST BE || LESS THAN 32KBYTES! Usually it is safe to use -ms and, in fact, can save a lot of memory when combined with -r residentable programs because the string constants will not be duplicated for each running instance of the program. SEE ALSO dcc, dcpp, dlink dice/dcc dice/dcc FUNCTION DICE Compiler Front End SYNOPSIS dcc options file file ... DESCRIPTION Dcc is the normal method of using the DICE system from a CLI window. Dcc automatically invokes all the other parts of DICE, relieving you of learning the grimy details. Dcc is similar to the UNIX cc command. Many users will prefer to use VMake, the visual interface to DICE. See chapter for full documentation. Dcc options may occur anywhere on the command line but MUST occur singly. That is, -c -a instead of -ca. file arguments to options may occur with or without an intervening space. -oFILE and -o FILE are both legal. Files ending in .a or .asm are assumed to be assembly files. Files ending in .l or .lib are assumed to be library files. Files ending in .o or .obj are assumed to be object files. All other files are assumed to be C source files. Normally DCC compiles all C source files, assembles all asm files, and links the resulting object files with any specified .o files together to produce an executable. The output file may optionally be specified with the -o option. If not specified, a default output filename based on the name of the input file is generated. This general action is modified by two options: -c DCC does NOT link, -o specifies the output object file -a DCC does NOT assemble (i.e. leaves the .a file resulting from a compile). -o specifies the output assembly file If neither option is given -o specifies the name of the resulting executable. The default object directory is T: and may be changed with the -O option. The default temporary directory is also T: and may be changed with the -T option. IF YOU HAVE LIMITED MEMORY you may have to specify that temporary files not be placed in T: either by re-assigning T: or using the -T option. DICE goes much slower if temporary files must be written to a floppy or even a hard disk. ## WARNING: asm files are assembled with DAS, See the assembler ## reference if you intend to assemble non-DC1 generated assembly file File to compile, assemble (.a), and/or link (.o, .lib) @@file containing further list of files, one per line. (blank lines and lines beginning with ';' or '#' are ignored. File may NOT contain further options). -E file specify stderr file, any errors are appended to file instead of to stdout. Useful for batch compiles -c Compile C source files and assemble into OBJECT files only (do not link). -a Compile C source files into ASSEMBLY files (do not assemble or link). Keep in mind the DAS will do further optimizations on the assembly file that you see. -l0 Skip linking default libraries (dlib:c.lib dlib:amigas.lib dlib:auto.lib), or standard startup (dlib:c.o and dlib:x.o). :: Beginner's Note: Do not use this option This option is used in special circumstances, such as when generating .libraries or .devices. ## WARNING: DICE is much more dependent on its startup code (c.o ## and x.o) than other compilers, do not link without the startup ## unless you know what you are doing. -l lib Include this library when linking. (space is optional) :: Beginner's Note: Use -lm to link with the math library. The :: math library is required before functions such as printf will :: work with floating point. See chapter for more information on linking in custom libraries. -3.0 -2.0 -1.3 Set the compiler to look for libraries and includes in the proper place. Libraries and includes are different for each operating system release. DICE eases compiling for, or using, different OS versions. DICE inserts the revision number into library names ("amigas30.lib") and the include file path ("dinclude:amiga30/"). -3.x -2.x -1.x Like the above options, except x specifies a specific minor OS revision. -L0 remove default library search path, including all explicitly specified (-L dir) directories up to this point. -L dir add the specified directory to the library search path. If the object module or library can not be found in the current directory, directories specified with -L are searched. -L directories are searched before the default library directory (DLIB:), assuming it was not removed with -L0 . Note that the directory path specified by -L is used to search for libraries AND object modules. A trailing '/' is optional -I0 Remove default include path from search list. The default include path is dinclude: and dinclude:amiga/ (unless modified by -1.x and -2.x options) -I dir When compiling scan this include directory (space is optional) The specified path takes precedence over defaults but defaults are NOT removed. -D define[=value] Pre-define a symbol -U Undefine __STDC__, mc68000, _DCC, and AMIGA. :: Beginner's Note: Do not use any of these options -Houtfile=headerfile This option enables precompiled header file generation and operation. You may specify any number of -H options. Example usage: -Ht:defs.m=defs.h When DICE encounters an #include <defs.h> this will cause it to first check for the existence of T:DEFS.M ... if T:DEFS.M does not exist DICE will generate it from <defs.h>. if T:DEFS.M does exist then DICE will use it directly and ignore <defs.h> You must specify the -H option both to have DICE create the precompiled header file and to have DICE use the precompiled header file. Normally one makes operation as transparent as possible so as not depend on the option existing when porting to other environments. ## WARNING: A precompiled header file contains the preprocessed ## header and preprocessor macros. These are set in stone! If you modify a #define that would normally effect preprocessing of a header file which is precompiled THE EFFECT WILL NOT OCCUR. It is strongly suggested you use precompiled headers ONLY with includes that are pretty much unchanging. For example, the commodore includes or otherwise have an appropriate dependency in your DMakefile or make script to delete the precompiled header file whenever any of your headers are modified. Normally one has a single -H option that enables precompiling of a local header file, say defs.h, which contains #include's of all other header files. Source modules would then #include <defs.h> :: Beginner's Note: Do not use this option -o file Specify output executable, object, or assembly file name depending on what you are producing. The space is optional -020 Generate code for the 68020 and later microprocessors -030 Generate code for the 68030 and later microprocessors -881 Generate inline FFP code for the 68881 -882 Generate inline FFP code for the 68882 :: Beginner's Note: Do not use any of these options These options exist to produce 020 and 030 opcodes, and 881/882 inline assembly for floating point operations. -md small data model (default) uses A4-relative -mD large data model uses absolute-long -mc small code model (default) uses PC-relative -mC large code model uses absolute-long :: Beginner's Note: Use only -mD if you declare more than :: 64KBytes of data. These options specify the default data and code model to use. The model may be overridden by use of the __near and __far type qualifiers on a variable by variable basis. DICE defaults to the small data and small code model, and is able to generate >32KBytes of code using the small code model so you should never have to use -mC. Note that the DICE libraries have all been compiled with the small-data model, and certain applications may disrupt the base register, A4... in this case use of the __geta4 type qualifier should be of use. If worse comes to worse you can recompile a large-data model c.lib, but I suggest you try other solutions first. -ms0 (default), Only const objects are put into a CODE hunk -ms String constants are put into the read-only code hunk -mS String constants are put into the read-only code hunk AND all external const references use NEAR addressing :: Beginner's Note: Use only -ms -ms0 turns off -ms/-mS in case you have it in your DCCOPTS environment variable and want to turn it off. Default operation (no -ms or -mS) puts const items into a read-only CODE hunk. Locally declared objects are referenced using PC-REL while external objects (declared in some other module) are referenced using 32-BIT ABSOLUTE addressing. -ms will additionally make all string constants, such as "fubar", const and referenced via PC-REL. -ms is an extremely useful option when you will never modify any of your string constants because the strings are not copied for multiple running instances of the program (if resident). -mS works like -ms, but in addition forces all external const references to use PC-REL addressing INSTEAD of 32-bit absolute addressing. || NOTE: This is a very dangerous option, do not use unless the || final code size is less than 32 kbytes. Using -ms along with -r can result in huge savings of memory due to the string constants being moved out of the data segment (which must be duplicated for each running instance of the program). ## WARNING: In all cases if you declare an object as const it ## must be extern'd as const in other modules or incorrect code ## will be generated. This is true whether you use -ms/S or not. -mRR registered arguments, strict This option controls the automatic registerization of procedure arguments. Only those prototyped procedures declaring 4 or fewer arguments will be registered. Values are passed in D0/D1/A0/A1 according to the type of variable and availability of registers. -mRR generates a single registerized entry point and extends registerization to indirect function calls (that must be fully prototyped). -mRR assigns either the registered or normal entry point to function pointers depending on whether they are prototyped or not (and any calls made through these function pointers will use the registered args method). ## WARNING: -mR cannot be used if you make c.lib calls that take ## call-back functions as arguments. -mr and -mRR CAN be used, however with -mRR you must be careful to supply the registered entry point. ## WARNING: AMIGA.LIB routines that take call-back functions as ## arguments must be given non-registered entry points. Thus if you use -mRR you MUST qualify the procedure or function pointer type specification with __stkargs to entire it has a normal entry point. -mw addr Used for making romable executables, Do not use to create AMIGA executables :: Beginner's Note: Do not use this option This option is another data model, called the ABSOLUTE-WORD data model. Source files compiled with this option generate absolute-word data references to access data objects instead of A4-relative or absolute-long. The base of the data segment must be specified as decimal, 0octal, or 0xHEX. Since absolute-word is used exclusive of A4-relative, the compiler will now use A4 for register variables. You may NOT mix -mw modules with small-data models. The ROMABLE program is usually run on the executable generated by DLink to generate a ROM. -ma addr Used for making romable executables, do not use to create Amiga executables :: Beginner's Note: Do not use this option This option specifies to the compiler and linker that the resulting code is intended to be relocated to a permanent data address, that specified by addr in decimal, 0octal, of 0xHEX. Unlike -mw, -ma assumes that the data segment can be placed anywhere. The ROMABLE program is usually run on the executable generated by DLink to generate a ROM. You may still specify a data model, -md or -mD, to Be with this option. Unlike -mw, -ma does NOT touch the A4 register and thus may be mixed with the small-data model. See the section on generating Romable code. -rom Set up options for generating romable code :: Beginner's Note: Do not use this option Like -l0, -rom disables automatic inclusion of a startup file (you must specify your own) and libraries. However, x.o is still included to sink any autoinit code. Your startup code must handle the appropriate model and call autoinit code before calling your program main This option is used to support ROMed firmware, i.e. non-Amiga executables. You should never link with c.lib. Instead, a new library, rom.lib, is available. rom.lib contains no static or global references and thus works with any data model, and only completely self-contained routines are included. The only data rom.lib uses is stack-based. All rom.lib routines are completely reentrant, including [v]sprintf() ! -proto Prototype checking and optimizations When this option is used, an ERROR message will be generated for any call that is not prototyped. This option is useful to ensure that you have properly prototyped routines (when you use prototypes), especially when floats and doubles are passed and indirect function pointers are used (they must be prototyped as well!). In the future this will enable stack-argument optimization. Currently, chars and shorts are extended to long's when pushed onto the stack for a subroutine call. In the future if the -proto option is used these objects will be pushed as shorts and not extended. -prof enable profiling for source modules -prof1 same as -prof -prof2 enable profiling for source modules and c*p.lib -prof3 enable profiling for source mods, c*p.lib, and amiga*p.lib Enable profiling. You may compile some or all your source modules with profiling enabled. Any -prof* option will enable profiling for compiled source modules. -prof2 will cause DCC to link with a profiled c*p.lib while -prof3 will cause DCC to link with a profiled c*p.lib and amiga*p.lib (the ultimate). To profile c*.lib and/or amiga*.lib functions the equivalent c*p.lib and amiga*p.lib must exist. These libraries are most likely lharc'd in DCC2:dlib/ or DCC3:dlib/ but if not, registered users may create any link library from the library source. -r Make executable residentable with separate CODE & DATA hunks -pr Make executable residentable w/ no relocation hunks -pi Make executable NON-residentable w/ no relocation hunks :: Beginner's Note: Just use -r to get residentable executables :: and do not worry about these other options. -pr/-pi generate 'position independent' code also useful for ROMed applications. NOTE that -pi and -pr force const items to be referenced pc-relative as well, causing -ms and -mS to do the same thing (when combined with -pr/-pi) Code size is limited to 32k bytes when you use -pr or -pi Refer to the RESIDENTABILITY section in Chapter 5 for a discussion of these options || NOTE: You may not make data references within const declared || objects when using the -r/-pr options. This is because the CODE hunk is shared between running instances of the program and these address references would be different between the instances. However, if you are using the -ms option, string constants will be in the code section and thus no problem. -O outdir Specify directory that is to contain output executable, object, or assembly files (used when specifying multiple source files) -O is useful to tell the compiler where to put the objects when you use dcc to compile and link a whole bunch of files at once. In this case, the -o option can still be used to specify where to put the final executable. || NOTE: The -O name is used as a prefix so if you are specifying || a directory be sure it has a ':' or '/' on the end. -R If the compile resulted in errors or warnings, execute the ARexx script specified in dcc:config/dcc.config. This activates the integrated error tracking features of DICE. -T tmpdir Specify the temporary directory used to hold preprocessed source files and temporary assembly files... files that will be deleted after use. || NOTE: The -T name is used as a prefix so if you are specifying || a directory be sure it has a ':' or '/' on the end. The default is T:. This option is useful in low-memory situations where you may decide to put intermediate files elsewhere. Putting intermediate files on your hard disc or floppy slows down compilation by an order of magnitude, but if you are running on a system with little memory you may not have a choice. -s Include symbolic debugging information in the executable (dlink option). This option includes the symbol table in the resulting executable and is passed to dlink. When using DOBJ to disassemble an executable, DOBJ will use the symbol table to generate a more symbolic dump. -S Alternate section naming op for libraries When making libraries: uses alternate section naming conventions so that all initialized data in the module will be placed before any initialized data in non -S modules (i.e. normal linked object files). Any library BSS will be placed before non-library BSS. Thus, the final ordering in the final executable will be: LIBDATA PROGRAMDATA LIBBSS PROGRAMBSS Thus, if your program contains >64K Bytes of BSS you can still link with a library that tries to reference its own BSS using the small-data model. If your library declares only initialized data (i.e. int x = 0; ), then you can link with the library even if your program declares >64KBytes of *initialized* data ! -v Display commands as DCC executes them. -new Checks timestamps for source/destination and only compiles/assembles if object is outdated or does not exist. Used to make DCC a standalone make. -f Fast CTRL-C handling for 1.3 This option is used for 1.3 only. You MUST be using the Commodore shell (NewShell) and if you make programs resident you MUST use the Commodore C:Resident command. This option will probably not work if you use WShell or ARPShell under 1.3. This option allows DICE to take short cuts to run sub-programs and allows CTRL-C to be propagated to said programs. This option is useful to set permanently in your DCCOPTS ENV: variable if you run under 1.3. DICE under 2.0 has no such problems and will run sub programs optimally, including propagation of ^C. -frag FRAGment (linker option). Tell linker not to combine all code hunks together or combine all data hunks together. Cannot be used if the -r or -mw options are used. Generally only useful if the large-data model is used. Not entirely supported yet. -ffp Set fp library for floats :: Beginner's Note: When using single precision floating point :: this option, use of the original ffp libraries, will make the :: program portable across all Amigas. Otherwise only amigas that have the Commodore MathIeeeSing*.library libraries will be able to run the program. If not specified, mathieeesingtrans.library and mathieeesingbas.library are used. These are new 2.0 libraries that may not exist on all machines yet. If specified, mathtrans.library is used .. Motorola's FFP float library. || NOTE: IF -ffp is used, be warned that conversion from floats || to doubles and back again is not entirely reliable. -d# Set debugging level (# = a number), used for compiler diagnostics only. -d opts Specify any combination of debugging options. These options may be combined in one -d option. Currently no options are defined. -gs Generate Dynamic Stack Code. This generates code on every subroutine call to check available stack. If available stack falls below 2K a new stack frame is allocated which will be deallocated when the subroutine returns. If the allocation fails, stack_abort() is called. If this routine is not defined by you, the library stack_abort() will call abort(). This option is extremely useful when compiling UNIX code that expects infinite stack. -chip CHIP force (linker option). Tell linker to force all hunks into CHIP memory. You should generally not use this option. Instead, use the __chip keyword for those specific data items that need to be in CHIP memory. || NOTE: CHIP data items are accessed using the large-data model, || thus you cannot create residentable executables that contain || __chip declarations Unless they are also const objects -- || read-only. -unix Causes DICE to use DLIB:uc*.lib instead of DLIB:c*.lib ... the uc*.lib is exactly the same as the normal c*.lib except that all filenames are assumed to be UNIX names .. that is, a beginning slash is converted to ':' (root of the current volume), "./" is ignored, and "../" is converted to "/" for all file accesses. This makes porting and usage of UNIX programs easier. -aztec The front end attempts to run Aztec executables -sas -lattice Identical. The front end attempts to run SAS/Lattice executables These options allow one to write a single DMakefile able to handle compilation under any compiler, assuming the source is compilable under any compiler. These are very limited options and may not work across new versions of Aztec or SAS/C -// This option enables C++ style // comments. This form of commenting begins with a // causing it and the remainder of the line to be considered a comment. -no-env This option disables DCCOPTS. DCC will not process options in the DCCOPTS environment variable. The ENV:DCCOPTS environment variable may contain additional options. ENV:must exist for DCC to run, even if you do not have a DCCOPTS environment variable. If you do not use ENV:,assign it to RAM: 1> assign env: ram: EXAMPLES: Example #1. Compile hello.c to create executable "hello.": 1> dcc hello.c 1> hello Example #2. Compile hello.c to executable "fish" and put the object file in X: 1> dcc hello.c -o ram:fish -TX: Example #3. Compile hello.c to and object file in RAM, then link with symbols: 1> dcc -c hello.c -o ram:hello.o 1> dcc ram:hello.o -o ram:hello -s Example #4. Compile foo.c and link with an already compiled object file gar.o to produce an executable. foo.o is placed in T: 1> dcc foo.c gar.o -o ram:foogar SEE ALSO das, dc1, dcpp, dlink dice/dcpp dice/dcpp FUNCTION DICE Preprocessor SYNOPSIS dcpp sourcefile [-o outfile] [-I includedir ...] options DESCRIPTION DCPP is a C preprocessor. C code is first preprocessed, then compiled. The preprocessing step resolves all # operators, like #define and #include, and generally prepares the C code for compilation. Most programmers use dcc or VMake, and do not invoke dcpp directly. Dcpp automatically scans DINCLUDE:, DINCLUDE:PD/, and DINCLUDE:AMIGA/ . Any -I option directories are searched in sequence BEFORE dcpp's default search path. The last default directory, DINCLUDE:AMIGA/, may be modified with the -1.3, -2.0 and -3.0 options. Note that DINCLUDE:PD/ is meant to be a place to put public domain header files so as not to clutter the top level DINCLUDE: directory. As with all DCC commands, the space between the option and an associated file/dir argument is optional. The following symbols are defined by default Symbol : Type : Usage ==============+=============+======================================= __LINE__ : integer : Current line number. : constant : --------------+-------------+--------------------------------------- __DATE__ : string : Current date. --------------+-------------+--------------------------------------- __TIME__ : string : Current time. --------------+-------------+--------------------------------------- __FILE__ : string : Current file. --------------+-------------+--------------------------------------- __BASE_FILE__ : string : Base source file. Allows an include : : file to know which C file included it --------------+-------------+--------------------------------------- __STDC__ : boolean : Indicates ANSI compiler. --------------+-------------+--------------------------------------- mc68000 : integer : Indicates Motorola CPU. : constant : --------------+-------------+--------------------------------------- _DCC : integer : Indicates the DICE system. : constant : --------------+-------------+--------------------------------------- AMIGA : integer : Everyone's favorite computer. : constant : --------------+-------------+--------------------------------------- _FFP_FLOAT : boolean : Set if single precision floats are in : : Fast Floating Point format --------------+-------------+--------------------------------------- _SP_FLOAT : boolean : Set if single precision floats are in : : IEEE-SING format (default). --------------+-------------+--------------------------------------- -1.x -2.x -3.x Selects operating system revision compatibility for the Preprocessor. If not specified, DCPP searches dinclude:amiga for amiga includes. If specified, DCPP searches dinclude:amigaNN for the includes. DCC supports this option and passes it along to dcpp. This allows developers to compile under any OS revision with the flick of an option. (Note: DCC also sets a different amiga.lib based on these options). -d[#] This option turns on DCPP debugging -ofile This option sets the output file, otherwise stdout is used. -ffp Passed from DCC, tells preprocessor to define _FFP_FLOAT. If not specified, preprocessor defines _SP_FLOAT. This exists to better support alternate floating point models in header files. -Dvar[=val] This option predefines a symbol or macro. -E file specify stderr file, any errors are appended to file instead of to stdout. Useful for batch compiles -U This option undefines the following symbols: __STDC__ mc68000 _DCC AMIGA -Hprecomp=header Enable use/creation of precompiled header files. See chapter for more information. -Ht:defs.m=defs.h -I0 This option causes DCPP to *NOT* include any default directories in the include search list. -I dir This option adds the specified directory to the include search list. A hanging slash on the end of the path is not required. The space is optional. -// Enable C++ style // comments. The remainder of the line after // is encountered is interpreted as a comment. This differs from /* style commenting in that no explicit comment-terminator is required. -notri Disable tri-graph scan pass. Note that the tri-graph pass is implemented in assembly and does not slow down preprocessing in any noticeable fashion, you should not disable tri-graphs unless you need to. SEE ALSO dcc, dc1 dice/DICEHelp dice/DICEHelp FUNCTION Fast Online Help Utility SYNOPSIS DICEHelp searchitem DESCRIPTION DICEHelp can quickly retrieve help on any DICE topic. From a CLI, simply type your request as above. From the Workbench, just click on the DICEHelp icon. Within many text editors, "hotkeys" have been established to link with DICEHelp. A key will either search for information on the word under the cursor, or bring up a box for your selection. DICEHelp uses a "fuzzy" search, so your never have to worry about getting the correct case or suffix. SEE ALSO Chapter . dice/dlink dice/dlink FUNCTION DICE Linker SYNOPSIS dlink options files libraries DESCRIPTION The final step in creating an Amiga program is linking. Normally the linker is invoked as needed by dcc or VMake. Options may occur anywhere on the command lines. Any file ending in .o or .obj is assumed to be an object file. Any file ending in .l or .lib is assumed to be a library. Any file name beginning with @@ specifies a text file containing a further list of files. File ordering is maintained. Section ordering is maintained. All sections of the same name are coagulated together with ordering maintained. || NOTE: Inter-section ordering is not maintained within a library || since library modules are random included. However, ordering is || maintained *between* libraries. All object files specified are included in the final executable. All libraries specified are searched at the point they are specified (that is, specifying an object file that references a symbol defined in a library specified BEFORE the object file will cause an undefined symbol error). Normally an object file is specified after a library to terminate an autoinit or autoexit section. You do not have to order object files within a library, DLink will automatically make as many passes as required to handle all internal library references. However, ordering object files will make DLink go faster. Symbols defined in object files override symbols defined in libraries. Symbols defined in libraries specified before later libraries override symbols defined in later libraries. Symbols defined in a library and also defined in a later specified object module causes an error. -o execname name of executable -s Include symbolic information. || NOTE: if -r is used symbolic info for the data sections will || point to the statically init'd stuff, NOT The actual data || space (in BSS) referenced by the code. This is a bug. -frag Fragment output file (default is to coagulate all hunks of the same type regardless of name). If frag is specified then only hunks of the same type AND name are coagulated. see fragmentation note at bottom -r[es] Resident link. -pi Position independent non-residentable (i.e. only one copy of the data but also no relocation hunks) -pr residentable position independent -Ppostfix specify library name postfix. If DLink cannot find the library as specified it will append the postfix and try again. Used by DCC to specify the memory model. -mw addr specify absolute data base -ma addr specify absolute data base Both options do exactly the same thing and are in duplicate to conform to DCC's options. -mw -ma specify the base of data as a decimal, 0octal, or 0xHEX address. You must use the -r option in conjunction with these options. DLink will resolve all Absolute-Word addresses but not all Absolute-Long addresses. This is left up to the ROMABLE program which generates a raw binary image of the program that can then be transferred to an EPROM. || NOTE: Do not use this option when generating Amiga || executables. -d[#] debug mode (spews lots of debugging junk out) -E file specify stderr file, any errors are appended to the file instead of to stdout. Useful for batch compiles -chip chip-only - forces all hunks into CHIP memory -L0 remove default library search path, including all explicitly specified (-L dir) directories up to this point. -L dir add the specified directory to the library search path. If the object module or library can not be found in the current directory, directories specified with -L are searched. -L directories are searched before the default library directory (DLIB:), assuming it was not removed with -L0 . Note that the directory path specified by -L is used to search for libraries AND object modules. A trailing '/' is optional -Ppostfix This allows you to specify -lc -Ps and DLink will automatically look for cs.lib ... you can specify a postfix that occurs before the .lib in the library name here. If DLink cannot find the library as it is named by default it will try it with the postfix. DCC uses this to supply the memory model to DLINK also allowing the user to say -lm in DCC and have it find MS.LIB if you are using the small-data model. CREATING A LIBRARY DLink libraries are standard Amiga libraries... simply join one or more object modules together and rename the result with a .lib extension. LINKER SYMBOLS DLink generates the following special symbols to aid in program startup: Symbol : Meaning ===============+===================================================== __ABSOLUTE_BAS : Base of data in volatile space. This symbol is NOT : defined for normal residentable programs since the : base address is not known (must be allocated : run-time) ---------------+----------------------------------------------------- __DATA_BAS : Base of data in non-volatile space. This symbol : points to a read-only copy of the initialized data : for a program. For Non-residentable programs this : is the same as __ABSOLUTE_BAS. For residentable : programs this points to a read-only copy of the : initialized data that the program can duplicate on : startup. For programs linked with an absolute base : address for data this points to the end of the CODE : section. The ROMABLE program always generates a : ROM copy of the initialized data just after the : CODE section (which startup code must copy into : RAM) ---------------+----------------------------------------------------- __DATA_LEN : Length of data space is longwords. i.e. : __DATA_LEN*4 yields the number of bytes of : initialized data. This is used by startup code to : copy read-only initialized data to volatile space : (residentable and data-absolute programs) ---------------+----------------------------------------------------- __BSS_LEN : Length of bss space in longwords. i.e. : __BSS_LEN*4 yields the number of bytes of : uninitialized (BSS) data. This is used in : combination with __DATA_LEN to allocate the : DATA+BSS space for residentable programs, and clear : the BSS space for non-residentable and : absolute-data-base programs. The BSS space occurs : after the DATA space unless the -frag option is : used. ---------------+----------------------------------------------------- __RESIDENT5D : This symbol is set to 0 if the -r option was used : and 1 if the -r option was not used. If set to 1 : (-r option) ---------------+----------------------------------------------------- Programs linked with the -mw or -ma options obviously do not 'allocate' their data space since it is predefined. Most Amiga programmers will never use the -mw or -ma options, by the way. SMALL DATA MODEL The small data model uses A4 relative addressing. The linker sets up all relative offsets such that A4 must be initialized by startup code the BaseOfInitializedData + 32766 for A4-relative references to access the appropriate address. RESIDENT If the -r options is given then NO BSS SPACE is allocated after the data space... the startup code MUST allocate a data+bss space as shown above. DLink will give error messages for any absolute data references that occur (except the __DATA_BAS symbol which must be used to copy the static data to the newly allocated data+bss memory on program startup). DLink will give an error message if any data-data reloco32s exist when you specify the -r option as such relocations would be incorrect when copied to the newly allocated data+bss space. DC1 understands this and will produce autoinit code to handle any such static data relocations that occur in your C code when the -r option is given to compile a C program. However, DLink does allow data-data relocations to occur if an absolute data base is specified along with the -r option. This is used only when making ROMABLE code. PC-RELATIVE Because the linker will insert a jump table for PC-RELATIVE references to different hunks (after coagulation) or where the range is larger than +/-32K, data should not be placed into a code segment and be referenced via an external label(pc) unless you are positive the reference is within +/-32K. This can only happen when referencing between like-named code hunks. NOTE that the jump table is tagged onto the end of the section the jump(s) occur in and thus you do not want to have any autoinit/autoexit code that might possibly generate a jump table (since the whole idea with autoinit is that the code falls through to other autoinit code until the terminating section in x.o's RTS). Currently dlink cannot handle inter-module PC-RELATIVE references beyond +/-32K (i.e. when one object file has more than 32K of code). An error will occur. Note that if -frag is used you cannot make PC-RELATIVE calls between sections of differing names ever, or make a program resident. The -frag option is almost never used on untested. || NOTE: When -frag is specified, the linker will not create a || special combined data+bss hunk (so data and bss can both be || referenced with one base variable). However, when -frag is NOT specified, the linker will stil not necessarily combine ALL data hunks into one big hunk and ALL bss hunks into one big hunk. Any data or bss hunk with special upper bits set (e.g. to force it into chip) is not combined into these special hunks, and any data or bss hunk whos NAME begins with 'far' (upper or lower case) will also not be considered. EXAMPLE This is what DCC gives the linker to link the program foo.c: dlink dlib:c.o @tmp dlib:x.o -o ram:foo Where tmp contains: foo.o dlib:c.lib dlib:amiga.lib dlib:auto.lib Basically it tells dlink to link the startup code, c.o, then the program object module(s) (foo.o), then c.lib, amiga.lib, and auto.lib, then finally x.o. DCC handles all this for you auto.lib contains autoinit code for certain selected libraries, including the dos.library. Autoinit code is brought in whenever a given library base symbol has been referenced BUT NOT DEFINED. auto.lib defines the symbol and generates autoinit code to open the library and autoexit code to close the library. To maintain portability you probably do not want to use this automatic library-opening feature yourself, it is really meant to support certain actions of the DICE library (such as floating point support). x.o terminates the autoinit and autoexit sections with an RTS instruction. The autoinit and autoexit sections are called from the startup code c.o. dice/dmake dice/dmake FUNCTION Make Utility SYNOPSIS dmake [file] DESCRIPTION Make utilities automate complex compiles. Makefiles can be considered recipes for complex programs. Makefiles contain "dependencies," which are rules that say things like "if this header file changes, recompile this C file." The idea with DMake is to provide a powerful make utility through general features rather than specialized hacks. DMake is governed by a few simple rules that can be combined into incredibly powerful operations. Generally you simply run DMake and have a list of dependencies in your DMakefile which DMake then executes. The DMakefile may contain three different kinds of lines: 1) COMMENTS -- Any line beginning with a '#' is a comment and ignored # This DMakefile generates an executable for fubar # The compiler options are as follows ... 1) ASSIGNMENTS -- Any line of the form SYMBOL = ... is considered an assignment. Any variable references from within the assignment will be resolved immediately. CFLAGS= -r SRCS= x.c y.c z.c 1) DEPENDENCIES: -- A line containing a list of symbols, a colon, and more symbols is assumed to be a dependency. Note that you cannot have a raw filename with a colon in it as that confuses DMake. Instead, use an ASSIGNMENT variable. Following the dependency line is zero or more command lines -- commands to run to resolve the dependency, terminated with a blank line. || NOTE: Not only is a zero-command dependency allowed, it is || sometimes necessary. A particular destination may have only ONE command list so if you have something like a.o : a.c with a command list to compile the source into an object you can also have another dependency such as 'a.o : defs.h' which would NOT have any associated command list. dst1 ... dstN : src1 ... srcN command1 command2 ... dst1 ... dstN : src1 ... srcN command1 command2 ... Finally, note that a dst* or src* symbol does not need to be a filename. It is perfectly valid to make up dummy names which are then used as the lhs of a dependency that collects other dependencies together. DEPENDENCIES When declaring dependencies you may use four different forms. The first form is to have a single destination and several sources. This is interpreted to mean that ALL the sources must be resolved before the single destination can be resolved via the command list for the dependency. The special variable, %(left), is set to the dst symbol and the special variable %(right) is set to ALL of the src symbols For example, this form would be used to indicate that an executable depends on all the objects being resolved before you can run the link. dst : src1 src2 src3 ... srcN The second form is the most useful in that it allows you to specify multiple 1 : 1 dependencies. Thus, you can specify, for example, that each object file depends on its source file counterpart for ALL the files in your project on a single line and have a single command list representing what to do (to compile a source file into an object, say). In this case %(left) and %(right) are set to each dst* : src* pair individually and the command list is run for any individual pair that is out of date. dst1 dst2 dst3 ... dstN : src1 src2 src3 ... srcN The next form may be used to specify that many files depend on one file being resolved. An example of usage would be to make all the object files depend on one header file. The command list, if any, is run for each dst* : src pair with %(left) set to the current dst* and %(right) set to the single source. dst1 dst2 dst3 ... dstN : src The last form is esoteric but sometimes useful. EACH dst* on the left hand side depends on the entire right hand side. You can have an arbitrary number of symbols on either side. %(left) will be set to a particular DST while %(right) will be set to all of the SRCs. for example, you could specify $(OBJS) :: $(HDRS) -- make all objects depend on all headers causing a recompile to occur if any header is modified. dst1 dst2 dst3 ... dstN :: src1 src2 ... srcI WILDCARDS DMake's most powerful feature is an easy to use file list replacement through options in a variable specification. You may insert the contents of any variable using the form: $(SYMBOL) Furthermore, you can make modifications to the contents of the variable on the fly using: $(SYMBOL:wildcard) only those files which match wildcard $(SYMBOL:wildcard:wildcard) matching files and also do a conversion Simple */? wildcarding is used. A wildcard may contain a colon or other punctuation but if it does you MUST surround it with quotes. Here is a quick example: SRCS= a.c b.c c.c d.c xx.a OBJS= $(SRCS:*.c:"dtmp:%1.o") all: echo $(OBJS) Will Produce dtmp:a.o dtmp:b.o dtmp:c.o dtmp:d.o The first wildcard specification restricts which files from the list are to be taken -- 'xx.a' was ignored, as you can see. Each '*' or '?' in the first wildcard specification corresponds to %N specifications in the second wildcard specification. You can prepend, insert, or append text and freely mix or ignore items matched to create your destination file list. This capability allows you to specify your source files EXACTLY ONCE in the DMakefile and then use the file munging capability to convert them to the object file list, etc... You can embed variables within variables as with the following example (note that this time xx.a is included): OD= dtmp:fubar/ SRCS= a.c b.c c.c d.c xx.a OBJS= $(SRCS:*.?:"$(OD)%1.o") all: echo $(OBJS) Will produce dtmp:fubar/a.o dtmp:fubar/b.o dtmp:fubar/c.o dtmp:fubar/d.o dtmp:fubar/xx.o As a side note, you may also specify '?' and '*' in the destination wildcard. These are considered dummies and are equivalent to %N where N is incremented from 1..9 for each '?' or '*' encountered. You can use the capability anywhere in the DMakefile. Another common thing to do is restrict your link line to include only the object files and skip the headers: $(EXE) : $(PROTOS) $(OBJS) $(HDRS) dcc %(right:*.o) -o %(left) ENVIRONMENT VARIABLES 2.0 local variables and 1.3/2.0 ENV: variables are fully accessible. Under 2.0 you can also modify local variables on the fly. DMake-specific variables override 2.0 local variables override ENV: variables. Under 2.0, any command containing <, >, `, or |, or is an alias, will be run with System(). Thus, such commands may not be used to modify local variables or the local environment. Also, such commands cannot be ^C'd due to the way AmigaDOS works. EXAMPLE The following is an example dmakefile. The variable $(FILES) is set to "main input output". The next two variables are constructed from $(FILES). The command $(FILES:*:"*.c") tells dmake to take $(FILES), look up each item ":*", and append two characters ":*.c". The results of the conversions are listed above. This unique feature of dmake makes for very elegant DMakeFiles. The first rule is the default rule, executed if you just type dmake. The rule, "sample:", states that the resulting program, "sample", is made up from the files listed in $(FILE_OBJECTS). If the date on "sample" is older than any dates in $(FILE_OBJECTS), the rule will execute. In turn, the next rule states that $(FILE_OBJECTS) ("main.o input.o output.o") are made from $(FILE_SOURCES) ("main.c intput.c output.c"). If any of the .o files are older than the corresponding .c file, the rule executes. In short, the makefile is a description of how source files inter depend. When any file changes, dmake figures the minimum number of steps to regenerate the final result. If you change just "input.c", only "input.c" will recompile. The last rule, "clean:", has no dependencies (nothing on the right side of the :). When executed, this rule deletes all the compiler-generated files, but not the source code. To execute this rule, type "dmake clean". Any number of rules may exist in a single DMakeFile. : DMakeFile - generic ------------------------------+------------------------------------- FILES = main input output : Equals "main input output" Set to FILE_SOURCES = : "main.c input.c output.c" Set to $(FILES:*:*.c") FILE_OBJECTS : "t:main.o t:input.o t:output.o" = $(FILES:*:"t:*.o) : ------------------------------+------------------------------------- sample: $(FILE_OBJECTS) dcc : Rule: sample is made from $(FILE_OBJECTS) -o sample : FILE_OBJECTS (defined above as : "t:main.o t:input.o t:output.o") ------------------------------+------------------------------------- $(FILE_OBJECTS) : : Rule: FILE_OBJECTS are made from $(FILE_SOURCES) dcc -c : FILE_SOURCES (see above). %(right) -o %(left) : ------------------------------+------------------------------------- clean: delete : Rule: "dmake clean" executes this $(FILES) $(FILE_OBJECTS) : delete command. ------------------------------+------------------------------------- LINE CONTINUATION AND ESCAPES Any line may be continued by terminating it with a backslash '\'. It is possible to escape the special characters '$' and '%' by doubling them though this is only necessary if an open-parenthesis follows the '$' or '%' and you do not want it interpreted as a variable. It is possible to escape ':' and other special characters by assigning them (or a string containing them) to a variable COMMAND SHELL Under 2.0 commands that do not contain any sort of redirection are run with RunCommand(). If a command is an alias or there is some sort of redirection in the arguments it will be run with System(). Under 1.3 everything is run with Execute() ADVANCED CAPABILITIES Now, you may have noted earlier that I said you could not have any given left-hand-side with more then one command list. Take, for example: a.o : a.c dcc %(right) -o %(left) a.o : defs.h <--- illegal to put command list here Actually, it isn't illegal. When DMake encounters a dependency without a command list it will automatically 'force' the next higher level dependency of the same left-hand-side. Therefore if you do not have a command list for the lower level left-hand-side things work as you expect. Note that this requires all such null dependencies to exist AFTER the one that has the command list. If you do have two or more command lists for the same left-hand-side they will run independent of each other according to their individual right hand sides. If several command lists apply then their order of execution will be bottom-up TEST FOR EXISTENCE Another advanced feature quite useful in fully automating the compilation process is the ability to create a directory tree on the fly. That is, if you have a projects called 'fubar' and want the objects to go into the directory DTMP:fubar/ you might want to have a dependency that creates DTMP:fubar if it does not already exist. XX= dtmp:fubar $(XX) : $(XX) makedir %(left) dice/dme dice/dme FUNCTION Editor SYNOPSIS Dme file DESCRIPTION Dme is a full screen programmable editor. See chapter for complete documentation. dice/makeindex dice/makeindex FUNCTION Build Index File for Online Help System SYNOPSIS MakeIndex outfile pattern DESCRIPTION MakeIndex builds a lookup file for the DICEHelp online help system. This file is normally called "s:dicehelp.index". Entries are always appended to outfile to allow building the index file in steps. Any number of files may be specified with wildcards in pattern. MakeIndex detects DICE documentation, AutoDoc files from Commodore, C include files and Assembler include files. Documentation files are indexed by the name of the function. C include files are indexed by structures. The names of assembler includes are recorded, but no additional processing is done. MakeIndex is normally run during the installation, or later by selecting the installer option "refresh DICEHelp index file." You may append your own selections using MakeIndex. SEE ALSO Chapter , Online help. dice/makeproto dice/makeproto FUNCTION Easily Create Prototype File SYNOPSIS makeproto infile outfile DESCRIPTION Collects lines beginning with the word Prototype from all your source files into a single header file. Each source module in a project normally includes a common header file, DEFS.H, which contains items common to the project. The idea is to add the following to your DEFS.H file: #define Prototype extern #define Local static /* or as nothing at all */ #include "protos.h" /* prototype file generated by MAKEPROTO Each source would contain prototypes that look like this (shown with example declarations): Prototype int FuGlob; Prototype void FuBar(int); Prototype struct MyFu *FuBar2(short); int FuGlob; /* etc... */ void FuBar(int x) { ... } You then create a PROTOS.H file by running MAKEPROTO on all source files. Among the tricks that are possible is the use of structure tags instead of typedefs in the prototypes themselves, allowing the prototype file to be #include'd during the normal course of compilation without necessarily requiring precursor includes to guarantee the validity of the types you use. Since a declaration containing a pointer to an undefined structure is valid as long as you do not try to access specific elements in the structure, this allows you to bring in prototypes for all functions in your entire project whether you use them in any specific source module or not. MAKEPROTO has one additional feature which makes its usage all the more efficient... if the specified output file already exists MAKEPROTO will compare its output with the existing file and not modify the date stamp of the file unless the output diffs. This is especially useful when you use precompiled includes where you might want to include a dependency to force the precompiled include to be recomputed if any header file OR the prototype file changes. Without this feature you would have to force the precompiled include to be recomputed every time you modify a source file because you would not be able to determine whether that modification resulted in a change in the prototype file PROTOS.H or not. dice/touch dice/touch FUNCTION Update File Datestamp SYNOPSIS touch file DESCRIPTION Touch bumps the date of a file without changing the contents. This is useful to force utilities like VMake and DMake to recompile source files. dice/VMake dice/VMake FUNCTION Visual Interface to DICE DESCRIPTION VMake is a complete control center for DICE. From within VMake you can manage a project, check files in or out of RCS, select files to edit, and finally compile and run your program. VMake is an alternate to the CLI-based dcc program. VMake is very flexible, and can be configured to control programs other than DICE. See chapter for a full description. dice/VOpts dice/VOpts FUNCTION Visual Interface for Setting Options DESCRIPTION VOpts provides an easy and powerful visual interface for selecting compiler options. Options may be specified explicitly, or simply left to defaults. VOpts is very flexible, can can be configured to set options for any program, not just DICE. See chapter for all the details. dice/wbrun dice/wbrun FUNCTION Simulate Starting a Program From Workbench SYNOPSIS wbrun file DESCRIPTION Wbrun is used by VMake to simulate the method used by the Amiga Workbench to start programs.