Fresh Fish 8/FreshFishVol8-CD2.bin/bbs/reviews/programmer.lha/programmer/DICE3.0_2

Internet Message Format | 1994-06-02 | 22.9 KB

Path: news.uh.edu!barrett
From: [e-mail] (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: [e-mail] (comp.sys.amiga.reviews moderator)
Distribution: world
Message-ID: <2sl5q8$[e-mail]>
Reply-To: [e-mail] (Ed Berger)
NNTP-Posting-Host: karazm.math.uh.edu
Keywords: programming, C, compiler, commercial
Originator: [e-mail]


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:    [phone]
            [phone]

    E-mail:        [e-mail]


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 <math.h> statement.

#ifdef _DCC            /* Compiling with DICE 3.0    */
#define PI    M_PI        /* DICE uses M_PI in <math.h> */
#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, [e-mail]

---

   Daniel Barrett, Moderator, comp.sys.amiga.reviews
   Send reviews to:    [e-mail]
   Request information:    [e-mail]
   Moderator mail:    [e-mail]
   Anonymous ftp site:  math.uh.edu, in /pub/Amiga/comp.sys.amiga.reviews