Path: news.uh.edu!barrett From: eb15@andrew.cmu.edu (Ed Berger) Newsgroups: comp.sys.amiga.reviews Subject: REVIEW: DICE Version 3.0 Followup-To: comp.sys.amiga.programmer Date: 2 Jun 1994 17:44:40 GMT Organization: The Amiga Online Review Column - ed. Daniel Barrett Lines: 503 Sender: amiga-reviews@math.uh.edu (comp.sys.amiga.reviews moderator) Distribution: world Message-ID: <2sl5q8$hip@masala.cc.uh.edu> Reply-To: eb15@andrew.cmu.edu (Ed Berger) NNTP-Posting-Host: karazm.math.uh.edu Keywords: programming, C, compiler, commercial Originator: barrett@karazm.math.uh.edu PRODUCT NAME DICE Version 3.0 BRIEF DESCRIPTION DICE 3.0 is the commercial version of the popular shareware DICE C language compiler created by Matt Dillon. The package contains a 450-page manual and 5 disks containing two different text editors, a C compiler, linker, debugging tools, source code management tools, source to the linker libraries, example programs and a 1.3 AmigaDOS compatible on-line help system. AUTHOR/COMPANY INFORMATION Name: Obvious Implementations Corporation Address: P.O Box 4487 Cary, NC 27519-4487 USA Telephone: (800) 761-2042 (919) 859-7407 E-mail: info@oic.com LIST PRICE Regular $150 US dollars Student (any school) $ 95 US dollars Owner of registered DICE $ 75 US dollars I upgraded from the registered version. SPECIAL HARDWARE AND SOFTWARE REQUIREMENTS HARDWARE 1M RAM required. More is suggested. 2 floppy drives disk space. Hard drive preferred. Battery backed clock recommended, but not required. SOFTWARE AmigaDOS 1.3 or higher required. AmigaDOS 2.x and 3.x compatible. COPY PROTECTION None. MACHINE USED FOR TESTING Amiga 3000/16, 12MB Fast RAM, 2MB Chip RAM. AmigaDOS 3.0 beta (purchased through the Commodore developer program) Seiko CM1440 VGA monitor INSTALLATION The package uses Commodore's Installer program. The installation script can be run multiple times for any additions to be made. A separate installation script is available for floppy users which uses a custom compression system. Installation of a large package like DICE -- with all its utilities, AmigaDOS-dependent revisions of the Commodore include files and linker libraries, compiler support options, numerous utilities, library source code, and example programs -- deserves some extra attention to the procedure, especially for beginner programmers. Here are two examples. An AmigaDOS 1.3-based A500/A590 owner might want a minimal installation. This might consist of AmigaDOS 1.3 include files, linker libraries, the DICE compiler with small data model and registerized parameters support, the debugger, and library and example source code. This takes up 2,258,513 bytes. An experienced developer might want a rather full installation. This might consist of all the include files, libraries, support of multiple data models, source control and debug utilities, and on-line help. This takes up 11,415,299 bytes of hard disk space. I recommend reading through chapter 6 of the manual to gain some more familiarity with the DICE programming environment before installing it. BUILDING PROGRAMS WITH VMAKE One of the highlights of the commercial version of DICE over previous releases is the new VMake utility. It integrates the whole DICE programming environment with a new graphic user interface (GUI). VMake is a very powerful and useful utility. It offers the inexperienced user the benefits of a 'make' program without having to learn all the strange syntax that Makefiles require. To use VMake on already existing source files, you invoke it either from the CLI or by the Workbench icon, and select "New" from the Project menu. A standard ASL requester appears (under AmigaDOS 2.04 and above), and you select the directory where your source is, and type in a name for the project. A '.dice' extension is added to the name. Next, you select "Scan" from the Edit menu, and VMake scans the directory for file. Delete any of the unnecessary files from the listing, and save the project. Voila: you have just created a Makefile! You can then select the "Options" menu item in the Edit menu to customize the compiler options such as OS Target, which debug level you want, optional places to search for include files or linker libraries, small code model or large code model. These options may be saved. All the things which you would change with the various switches if you were compiling from the CLI are available through the graphic user interface. Now to compile and run your program, you press the "Make" button or use the Compile menu, and off DICE goes, compiling your project. You can then run your program by hitting the Run button or selecting the appropriate menu items. You can simulate running your program from Workbench, or feed CLI arguments to your program by way of the "CLI Arguments" string gadget. A menu option is available to run your program through the debugger as well. It's a smooth and easy-to-use environment. VMake is also a lot more. Instead of all those gadgets and menu items being hard coded into the program, VMake uses extensible configuration files. If you don't like a menu hotkey, just edit dcc:config/vmake.config to make the change. For example, I didn't like using Amiga-Y for the "Project New" subitem. My VMake is now a little more Style Guide compliant with Amiga-N in its place. While VMake normally opens on the Workbench screen it also supports 'jumping' from one public screen to another. I would have liked VMake to use the Amiga Style Guide command line keyword and icon tooltype "PUBSCREEN" so that I could have it open automatically on the particular screen I want. But jumping is better than nothing. Further customizing of the VMake environment is available through ARexx. VMake comes preconfigured fairly well. REVISION CONTROL AND EDITOR INTEGRATION One of the most useful features that VMake integrates into the programming environment is revision control via the "RCS" and "UpRev" utilities. RCS (Revision Control System) has been used for years on UNIX platforms, where developing large projects with multiple programmers can lead to problems. RCS provides a way of tracking multiple versions of a program or its pieces. It helps you to find newly created bugs in your programs by allowing you to compare various revisions of a file and look over the differences. VMake integrates RCS into its GUI, allowing you to concentrate on your code and not on the command line switches required to learn RCS. I always told myself that I was going to learn RCS some day, but now I don't really have to. :-) To "check in" a file under RCS/VMake, you just click on the filename in the VMake listview and select the RCS Menu "Check In" subitem. Fill in the "initial comment" prompt on the VMake console window, followed by a line with just a period. RCS then makes an "rcs" subdirectory in the current directory, and sets the current file protection to read-only. If you then want to change that file by popping up your editor, just double-click on the filename in the VMake listview and you are presented with a requester telling you that the file is read-only and do you want to check out the file from RCS? Select "Yes", edit the file, and then check it back in with RCS when you are done, this time entering comments about what changes you made. You can review the change history on demand. UpRev generates an Amiga User Interface Style Guide type of revision string that you can use in your programs. VMake has an Edit menu subitem for UpRev. When used the first time, it creates an include file PROJECTNAME_rev.h where "PROJECTNAME" is the name of your project. If you include this header file in your your program file which contains main(), and add a line like: const char my_version_string[]=VERSTAG; you automatically get an Amiga User Interface Style Guide compliant version string in your program, which you can easily update any time you've made changes to your program by simply choosing the edit menu subitem 'Update Revision' and recompiling the program. Together, RCS, UpRev, and VMake handle revision control very well. Now, on to integration with a text editor. I installed DICE with TurboText integration, so I cannot write about how it functions with other editors such as the included AME and DME editors. After you have created a VMake project, you can double-click on any of the files listed in the Project listview gadget and bring up your editor with that file. If the compiler finds an error when building a project, it invokes the text editor, loads the file containing the error, and places the cursor on the line where the error occurred. With TurboText, it displays the current error in the window title bar and then reactivates the Vmake console window. This causes some minor problems. First, the error message might be too long to fit in the title bar, and second, the title bar is cleared when the TurboText window is deactivated. So, I have to go back to TurboText's window and pick the DICE menu item "Current Error" to see what the error was. I think DICE should printing its error message on the VMake console window AND signal TurboText. Another minor problem occurs when your source files have multiple errors. As you are looking over the first one, DICE signals the editor to go onto the next one underneath you, or worse yet, opens another file window in front of the one you are currently reading, when you don't expect it. With all the configurability of both VMake and TurboText, I presume I will be able to change this to my liking when I have some more time. THE DICE DEBUGGER The DICE debugger "DD" is also new in the Commercial version of DICE. Unfortunately for this review, it is also one of the parts of the system that I haven't had much time with. A debugger is very useful for finding the more subtle bugs in your programs. I'll use an example from my real world experience to illustrate this. I had written a public screen program and used it for months before I realized it had an Enforcer hit bug. One day, apparently out of the blue, I got an Enforcer hit from my program which I had been using every day. A few days later, another one occurred. I had no idea what caused the problem: perhaps a new utility running in the background? A week or so later, when I wasn't particularly busy, I saw another Enforcer hit, but this time I noticed it had something to do with using the menus. I tried every menu item and couldn't reproduce the hit. I looked over my source code and didn't see anything obvious. I played some more with the menus and BINGO: I found a reproducible Enforcer hit caused by pulling the mouse past the bottom of the Project menu and letting go of the right mouse button. I looked over my source code again, and still didn't see anything obviously wrong according to my understanding of handling menus. I decided it was time to learn how to use a debugger (SAS/C's CodeProbe). By compiling the program with the appropriate debug options, and then running the program under control of the debugger, I was able to find that while I was trying to read certain data from the Intuition message generated by a menu event, I wasn't handling the case produced by 'MENUNULL' properly. I was comparing my data with a strange location in memory when the user selected a menu but not the subitems. In that case, the program was trying to read data which wasn't valid. This generated the Enforcer hit. I then added an additional check for the MENUNULL messages to my code before trying to read the Intuition message data, and the Enforcer hit disappeared. I don't know how long it would have taken to realize this was the problem without the help of a debugger. Now, on to DD. I recreated my MENUNULL bug as mentioned above, and DD was able to show me the same basic information that I got from the SAS/C debugger. DD has many options for displaying your code and system information using multiple windows. My only real complaint about DD is the lack of documentation and tutorials for beginners on how to use it. Only on-line documents are available. A full chapter in the manual, with screen shots and tutorial examples, would be a welcome addition. DD supports ARexx, and the on-line documentation says that the full source code to DD will be made available in the future for even more customizing options. Remember that if you find reproducible bugs in other people's programs, such as Enforcer hits, you should send a detailed report of how the to reproduce the bug, so the author can fix it and produce more reliable Amiga software. A simple message that "it gives Enforcer hits" is of little use when the author doesn't see it on his system by the way he uses the program. The details of dragging the mouse beyond the menu and releasing the button while not selecting anything made finding the programming error possible. SOURCE CODE COMPATIBILITY TESTS I tested DICE by compiling a bunch of Amiga and UNIX source code, including: Amiga Source Code: RKM Example source code published by CATS on Fred Fish disks 741-742. AmigaMail Jan/Feb 1990 'modular event processing' by David N. Junod. ACE Graphics example code published by the Amiga C Club (registered). An unreleased version of my own public screen program. Dave Haynie's articles on C programming in May/June 1994 AmigaWorld. BOOPSI & MUI example code pulled off the Aminet FTP sites. UNIX Source Code: Gplot -- CGM to Postscript conversion program from PSC. Bwbasic 1.11 -- a minimal ANSI BASIC language interpreter. Tcl 7.3 interpreter. Since this is an Amiga compiler, lets look at the results of that first. Practically all the Amiga examples from the RKMs, AmigaMail, ACE, and my public screen program compiled and ran fine after making minor changes to the code, which gave exit code #20 (failed to compile): Error 83: Too many initializers -- usually caused by structure assignments with an extra comma in them like: struct Border buttonBorder = { -1,-1,1,0,JAM1,5,buttonBorderData,NULL, }; ^^^ extraneous comma Error 68: Expected semicolon -- usually caused by non ANSI compliant compiler specific keywords like: UWORD chip bottom_sprite_data[36]= ^^^^ should be __chip (with 2 underscores) Dave Haynie's example programs worked fine when I added the following after the #include statement. #ifdef _DCC /* Compiling with DICE 3.0 */ #define PI M_PI /* DICE uses M_PI in */ #endif /* End DICE 3.0 specifics */ The BOOPSI example programs presented more difficulty as some of them used assembly files as well, and DAS (the assembler provided with DICE) isn't a general-use assembler. Try a68k or PhxAss (both freely available on Aminet) or a commercial assembler. Conversion from Manx code was fairly easy as you just remove the "geta4()" function on a subroutine and add the "__geta4" keyword to its definition, remembering to compile the subroutine with stack checking off. The commercial version of DICE seemed to swallow the SAS/C specific __saveds and __asm keywords, when I expected it to give an error. The official MUI demo programs compiled with minimal problems. I did have a problem with compiling a third-party, MUI-based image class -- MyImageGClass.c. When I tried, DICE gave the error code #116 -- Subroutine to complex to generate code for. The example compiles fine with SAS/C 6.51, and I didn't feel like learning MUI programming to try to work around this error code/bug just for this review. Now for UNIX compatibility. Give the time allotment for completing this review, I wasn't able to compile any of my UNIX oriented examples with DICE, even though I had already adapted them to SAS/C 6.51. The problems I encountered were: Gplot: Somewhere in the source, the sscanf() function was used with the "%e,E,f,g,G" format options, and these are not currently supported by DICE. The resulting program gives a runtime error: 'Error: *scanf:%e,E,f,g,G, only 'l' double format currently supported'. With some more time, I could have located the pieces of code and perhaps rewritten the routines accordingly. Bwbasic: The DICE link libraries were missing the functions fmod() and putenv(), so the final program would not link. With some more time, I could have written my own equivalents of these functions. Tcl: The source code was written with UNIX or POSIX based systems in mind, to the point that it expects UNIX script files to generate an appropriate Makefile for the package by looking in the various systems include files, etc. I got most of the library to compile using the same work-arounds as I used for SAS/C, but when it came time to link the tcltest program, I was missing the math functions: fmod(), cosh(), sinh(), and tanh(). The hypot() function was also missing in SAS/C 6.51. DOCUMENTATION DICE 3.0 comes with a 450-page printed manual and on-line documentation. The 450-page manual begins with an introduction of the product and its installation. It then gives an overview of the C language which should be quite helpful to those who are fairly new to C, and give a quick refresher to those who haven't programmed for a while. This is followed by a section geared towards BASIC programmers who are new to the C language. The next section is on using the VMake utility. It gives a good overview of how to use the program at the beginner level, and follows through with how to customize the VMake environment with its configuration files and ARexx for those with more experience, or if you have a special need. The next chapter gives an overview of using the CLI tools such as the front-end program dcc, and gives some compatibility hints for those folks switching over from Manx or Lattice compilers, along with specific information regarding the DICE/Amiga/ARexx programming environment. The next seven chapters offer reference material for the commands, assembler, DME and AME text editors, On-line Help, Library functions, and Error Codes. The last chapter is a quick help guide focusing on common C programming errors and common Amiga programming mistakes. The section for describing the debugger only points you to the on-line document. DICE 3.0 also has documentation on-line and available through the DiceHelp program. If you have Commodore's AutoDocs on disk, you can add them to the DiceHelp database during the program installation. DiceHelp is an AmigaDOS 1.3 compatible system that can run from the Workbench or CLI. When started from the Workbench, a simple requester pops up that asks you for a search string. After you type in a search string, it pops-up a window that lets you page through the document. I had problems using DiceHelp through the CLI, as there was no paging, and long documents just scrolled off the window too fast to view. While I like the fact that you can use the standard console drag to copy pieces of the documentation to the Amiga clipboard, I'd like a more friendly method for browsing through the help files such as a listview of topics, or an array of buttons like AmigaGuide, as well as the string gadget. DiceHelp has ARexx support and can be integrated with your text editor by writing its output files to the Amiga clipboard, a temporary file in t:, or to stdout. I haven't taken the time to investigate these options yet.... LIKES I really like VMake's integration with RCS and UpRev. I like the overall configurability of VMake. I like the overall speed of the DICE compiler, even though I haven't optimized my setup. It's quick! I like all the Amiga specific support for keywords like __chip and registerized function arguments. I like the debugger, even though I haven't got into it very much yet. It appears to be quite functional. DISLIKES AND SUGGESTIONS I dislike the current handling of errors affecting the editor while I'm looking over the first one. I think a facility like SAS/C's message browser would be more functional for me. I think there could be better documentation for beginners regarding installation, going step by step. I think printed documentation for the debugger would be helpful, including screen shots and some tutorial example programs. I dislike the missing functions in the linker libraries. I think they should add the functions that SAS/C has, and then add some more. Perhaps a richer UNIX-compatible function linker library should be developed to ease porting code to AmigaDOS. I'd like a better front-end and user index to the DiceHelp files. Finally I'd like a pretty box to hold the manual and disks while they're on the shelf. COMPARISON TO OTHER SIMILAR PRODUCTS I've been using SAS/C 6.51, which is an excellent product, and I have used older versions of GCC up to version 2.3.3. If we ignore the C++ compatibility issue, since DICE 3.0 does not compile C++ code, there are several areas that deserve comparison. Here's how I think they compare, on a scale of "A+" (best) to "F" (worst). Integration of the programmers environment: DICE 3.0 A- SAS/C 6.51 B+ GCC 2.3.3 C Resource requirements usage: DICE 3.0 A SAS/C 6.51 A GCC 2.3.3 D ( I'd suggest 8M Fast RAM minimum ) Speed of compiler to create programs: DICE 3.0 A SAS/C 6.51 A GCC 2.3.3 C Speed of executables created by compiler: DICE 3.0 B SAS/C 6.51 A ( CPU/FPU specific support and optimizations ) GCC 2.3.3 A ( CPU/FPU specific support and optimizations ) Compatibility with available Amiga source codes: DICE 3.0 B+ SAS/C 6.51 A- ( Lattice/Manx related tools and docs help here ) GCC 2.3.3 C- ( no __chip , no geta4()? [not sure] ) Compatibility with available UNIX source codes: DICE 3.0 C+ SAS/C 6.51 B+ GCC 2.3.3 A+ Understandability of compiler error and warning messages: DICE 3.0 B SAS/C 6.51 A+ GCC 2.3.3 B Not one of the compilers is the best at everything. I think I'll integrate my SAS/C environment with DICE/VMake and maybe later when I buy a CD-ROM drive, I'll add GCC off the most current 'Fresh Fish' CD to my collection of development tools. BUGS The "subroutine too complex" error noted in the SOURCE CODE COMPATIBILITY TESTS section, above. VENDOR SUPPORT Obvious Implementations Corp. responded to a non-technical problem by email in a couple of days. I haven't had further need to contact them. They have been responding promptly to Usenet messages posted about DICE. WARRANTY None. CONCLUSIONS DICE 3.0 is definitely a worthwhile upgrade from the shareware or freeware versions of DICE. DICE 3.0 also makes a nice addition for folks with either the SAS/C 6.51 or GCC compilers. If you are running an older compiler such as the Lattice C, Manx C, or SAS/C 5.1, you should definitely consider upgrading to DICE 3.0 or SAS/C 6.51. Amiga compilers have come a long way in the last couple of years. COPYRIGHT NOTICE This review is released to the public domain. Ed Berger, eb15@andrew.cmu.edu --- Daniel Barrett, Moderator, comp.sys.amiga.reviews Send reviews to: amiga-reviews-submissions@math.uh.edu Request information: amiga-reviews-requests@math.uh.edu Moderator mail: amiga-reviews@math.uh.edu Anonymous ftp site: math.uh.edu, in /pub/Amiga/comp.sys.amiga.reviews