Club Amiga de Montreal - CAM/CAM_CD_1.iso/files/387b.lha/dice_v2.02/doc/COMPILER.DOC

Text File | 1990-05-30 | 7.3 KB | 197 lines

                   DICE SYSTEM

                  V2.0

                  Matthew Dillon
                  891 Regal Rd.
                  Berkeley, Ca. 94708
                  USA

                  uunet.uu.net!overload!dillon

    Refer to doc/DCC.DOC for compiler options.

    Refer to doc/README.FIRST for copyright and shareware information.

    (1) SETUP

    You must purchase the amiga includes and amiga.lib from commodore
    separately.  If you are a developer you ought to have these.  I
    have not turned in my licence form to be able to distribute 1.3
    includes yet, sorry!

    The preprocessor automatically scans the following directories:

    DINCLUDE:        location of top level includes such as stdio.h
    DINCLUDE:Amiga/     location of amiga includes (e.g. amiga/exec/types.h)
                (amiga includes not included)

    DCC references startup and libraries to DLIB:

    DLIB:amiga.lib        A small-data model version of AMIGA.LIB (not included)
    DLIB:c.lib        The main C library for which you have source code
    DLIB:auto.lib        The auto library-open library
    DLIB:c.o        The startup module
    DLIB:x.o        The terminator module (for autoinit sections)

    (2) AMIGA.LIB

    You need to run the LIBTOS program on your AMIGA.LIB to produce a
    small-data model AMIGA.LIB:

    libtos youramiga.lib DLIB:Amiga.lib

    This converts all absolute data references to base variables to
    A4-relative references, allowing programs to be made residentable.

    (3) COMPILER EXECUTABLES

    Compiler executables should be made RESIDENT if possible.  DCC runs
    DCPP, DC1, DAS, and DLINK.

    DCC        compiler front-end
    DCpp        preprocessor
    DC1        main compiler pass
    Das        minimal assembler
    DLink        linker

    --------------------------------------------------------------------------
                COMPILER FEATURES LIST

    (0) ANSI.  Pretty much ansi.  Please report non-ansism problems.

    (1) autos are placed in registers based on weighted usage.  A0,A1,D0,D1
    will be used as register variables whenever possible, which usually
    reduces the number of registers that must be saved/restored in
    critical low level routines.

    (2) LINK/UNLK is removed from low level routines that do not reference
    A5 and do not make any subroutine calls

    (3) MOVEM is converted to MOVE or deleted entirely

    (4) Various obvious optimizations:  use of BSET, BCLR, BTST as short
    cuts to logic operations, CMP/TST, etc...

    (5) Switch() statements are optimized as follows:

        * if the range of values is less than double the number of cases
          a lookup table will be used

        * otherwise subq/beq is used, but if the range of values is
          within the size of a word then word operations will be used
          instead of long operations.

    (6) Branch optimization.  Bxx to BRAs are optimized (up to 20 hops) by
    DAS, and massive optimization is done to multi-level conditionals
    by the main compiler pass

    (7) Workbench support.  The standard startup module supports the workbench.
    Specifically, the low level _main() in c.o does this.

    When a program is run from the workbench, a different entry point is
    called:     wbmain(wbmsg)

    If you do not supply a wbmain() then the one from the c.lib library
    is used which immediately return(-1)s, exiting the program.

    (8) _main() shortcut for extremely low level programs.

    You may overide c.lib's _main with your own.  If you do so you may
    not use any memory allocation, stdio, or fd (open,close...) related
    routines.  The startup module (c.o) will still run autoinits,
    autoexits, setup resident programs, and initialize your BSS space.

    _main(len, arg)     (as passed to the program on startup)
    long len;
    char *arg;
    {
    }

    If running from the workbench, you must GetMsg() and process the
    workbench startup message yourself, as well return the message
    when you exit.

    _exit exists in c.o and cannot be overridden.  If you use the _main
    override you may NOT call exit() unless you also override it.
    Calling exit() will generate references to stdio library code and
    bring it in from the library, making your executable larger
    unnecessarily.

    (9) AutoInit support.  You may qualify a subroutine with the _autoinit
    keyword that will cause it to be automatically called by the
    startup code rather than having to explicitly call it from main.

    This feature is more useful to bring code in indirectly.  For
    example, to automatically OpenLibrary() (& CloseLibrary()) floating
    point libraries if their base variables are referenced.  (p.s., fp
    is not implemented in DICE yet).

    Refer to the auto.lib source code for examples.

    (10) DCC runs fast.  Make everything resident and watch it fly.  Most
     of this speed comes from loading entire files into memory at once.
     This might present a memory program though in general DCC will use
     less memory than either Lattice or Aztec.

    (11) CODE SIZE is comparable with Lattice and Aztec, even better in
     many cases.  The minimum program sizes are as follows:

    _main() { }          388    no stdio/fd
     main() { }         2800    some stdio
     main() { printf }  5200    most of stdio

    ------------------------------------------------------------------------
                   COMMENTS

    Registerized parameters are not implemented.  Registerized parameters
    work well only in a few limited cases.  In general, they do not add
    much in the way of efficiency to small routines that do not get passed
    much anyway, and must be moved or stored back onto the stack for larger
    routines to allocate more critical local variables into registers, not
    to mention complication to the caller.  A good implementation of
    registerized parameters might put one or two parameters in registers.
    Most implementations I have seen attempt to use all the scratch
    registers and even some non-scratch registers.

    So, cute, but not as much of a boost as you might think.

    Inline library calls are not implemented either.  Inline library calls
    are actually useful and when properly implemented increase efficiency
    to low level calls such as AddHead() and GetMsg().  Other calls such as
    Move() and Draw() do not increase noticably in efficiency.

    #pragma's must be used to define inline calls and this makes the compiler
    enviroment less portable.  Lattice made a big mistake *requiring* the
    use of inline library calls with residentable programs.  My solution was
    to write a program to convert AMIGA.LIB into a small-data version of same.

    In general, I refuse to implement a thousand nearly useless features that
    will only introduce more bugs into the compiler.

    ------------------------------------------------------------------------
                COMPATIBILITY

    Except for the lack of floating point and some Cisms that have not been
    implemented yet (such as bit fields and floating point), DCC should
    compile just about anything.

    I spent a great deal of time ensuring that STDIO routines run relatively
    fast.  I decided to write nearly all of the support library in C instead
    of falling back to optimized assembly to keep the system uniform.  One
    does not notice much of a difference between the C strcpy() and an
    assembly strcpy() relative to the run time of their program.  Currently,
    however, the longword divide is sorely lacking.

    ------------------------------------------------------------------------

                Your first program

    1> dcc examples/hello.c -o ram:hello
    1> ram:hello
    hello world
    1>