home *** CD-ROM | disk | FTP | other *** search
/ AmigActive 13 / AACD13.ISO / AACD / Programming / vbcc_MorphOS / doc / vbccm68k.doc < prev    next >
Text File  |  2000-08-20  |  13KB  |  309 lines
  1. vbcc - C compiler (c) in 1995-2000 by Volker Barthelmann
  2.  
  3.  
  4. INTRODUCTION
  5.  
  6.     vbcc is a free portable and retargetable ANSI C compiler.
  7.     It is clearly split into a target independant and a target dependant
  8.     part and supports emulating datatypes of the target machine on any
  9.     other machine so that it is possible to e.g. make a crosscompiler for
  10.     a 64bit machine on a 32bit machine.
  11.     This document only deals with the target dependant parts of the
  12.     Amiga68k version.
  13.  
  14.  
  15. LEGAL
  16.  
  17.     vbccm68k is (c) in 1995-2000 by Volker Barthelmann.
  18.     This is a development snapshot which must not be distributed.
  19.     Commercial usage is forbidden.
  20.  
  21.  
  22. ADDITIONAL OPTIONS FOR THIS VERSION
  23.  
  24.     -cpu=n      Generate code for cpu n (e.g. -cpu=68020), default: 68000
  25.  
  26.     -fpu=n      Generate code for fpu n (e.g. -fpu=68881), default: 0
  27.  
  28.     -sd         Use small data model (see below).
  29.  
  30.     -sc         Use small code model (see below).
  31.  
  32.     -prof       Insert code for profiling (not really usable yet).
  33.  
  34.     -g          Generate debugging hunks which contain addresses of static
  35.                 objects and links assembly instructions to source lines.
  36.                 This does not work with -gas.
  37.  
  38.     -const-in-data
  39.  
  40.                 By default constant data will be placed in the code
  41.                 section (and therefore is accessable with faster pc-relative
  42.                 addressing modes). Using this option it will be placed in the
  43.                 data section.
  44.                 This could e.g. be useful if you want to use small data and
  45.                 small code, but your code gets too big with all the constant
  46.                 data.
  47.                 Note that on operating systems with memory protection this
  48.                 option will disable write-protection of constant data.
  49.  
  50.     -use-framepointer
  51.  
  52.                 By default automatic variables are addressed through a7
  53.                 instead of a5. This generates slightly better code, because
  54.                 the function entry and exit overhead is reduced and a5 can be
  55.                 used as register variable etc.
  56.                 However this may be a bit confusing when debugging and you
  57.                 can force vbcc to use a5 as a fixed framepointer.
  58.  
  59.     -no-addressing-modes
  60.  
  61.                 The intermediate code does not contain any of the 68k
  62.                 addressing modes, so if they are to be used an extra pass
  63.                 over the intermediate code is necessary to recognize certain
  64.                 patterns that can be expressed using a 68k addressing mode.
  65.                 By default vbcc tries to use some 68k addressing modes.
  66.                 Currently (ax)+ and subsets of (displ,ax,dy*skal) are used.
  67.                 However not all cases where those addressing modes could be
  68.                 used are recognized.
  69.                 With this option you can prevent vbcc from searching for
  70.                 possible addressing modes. This may simplify debugging.
  71.  
  72.     -no-delayed-popping
  73.  
  74.                 By default arguments of function calls are not always popped
  75.                 from the stack immediately after the call, so that the
  76.                 arguments of several calls may be popped at once.
  77.                 With this option vbcc can be forced to pop them after every
  78.                 function call.
  79.                 This may simplify debugging and very slightly reduce the
  80.                 stack size needed by the compiled program.
  81.  
  82.     -gas        Create output suitable for the GNU assembler. This is
  83.                 mainly useful to create code for other operating systems.
  84.  
  85.     -no-fp-return
  86.  
  87.                 Do not return floats and doubles in floating-point registers
  88.                 even if code for an fpu is generated. This is mainly useful
  89.                 to create code for other operating systems.
  90.  
  91.     -no-mreg-return
  92.  
  93.                 Do not use multiple registers to return types that do not
  94.                 fit into a single register. This is mainly for backwards
  95.                 compatibility.
  96.  
  97.     -d2scratch  obsolete
  98.  
  99.     -noa4       obsolete
  100.  
  101.  
  102. SOME INTERNALS
  103.  
  104.     The current version generates assembler output for use with the PhxAss
  105.     assembler (c) by Frank Wille. Most peephole optimizations are done by the
  106.     assembler so vbcc only does some that the assembler cannot make.
  107.     The generated executables will probably only work with OS2.0 or higher.
  108.  
  109.     With -gas assembler output suitable for the GNU assembler is generated
  110.     (the version must understand the Motorola syntax - some old ones do not).
  111.     The output is only slightly modified from the PhxAss-output and will
  112.     therefore result in worse code on gas. However this code generator should
  113.     be usable on most operating systems on 68k machines that way.
  114.  
  115.     The register names are:
  116.  
  117.          a0,  a1,  a2,  a3,  a4,  a5,  a6,  a7
  118.          d0,  d1,  d2,  d3,  d4,  d5,  d6,  d7
  119.         fp0, fp1, fp2, fp3, fp4, fp5, fp6, fp7
  120.  
  121.     The registers d0, d1, a0, a1, fp0 and fp1  are used as scratch registers
  122.     (i.e. they can be destroyed in function calls), all other registers are
  123.     preserved.
  124.  
  125.     All elementary types up to 4 bytes are returned in register d0 like
  126.     common on the Amiga (although I think pointers should better be returned
  127.     in a0). If compiled for an fpu, floating point values are returned in
  128.     fp0 unless -no-fpreturn is specified.
  129.     Types which are 8, 12 or 16 bytes large will be returned in several
  130.     registers (d0/d1/a0/a1) unless -no-mreg-return is specified.
  131.     All other types are returned by passing the function the address
  132.     of the result as a hidden argument - so when you call such a function
  133.     without a proper declaration in scope you can expect a crash.
  134.  
  135.     You must not link objects together that have been compiled with
  136.     different settings!
  137.  
  138.     vbcc uses d0-d7 and a0-a6 for temporary results and register variables
  139.     (a4 is used as small data pointer if -sd is used). a5 can be
  140.     used as frame pointer for automatic variables (but this is not necessary -
  141.     they can be accessed through a7, too). At the moment all local
  142.     variables are addressed via (dist,ax), so a function may have only ~32k
  143.     of local variables if code for <=68000 is generated.
  144.  
  145.     The elementary data types are represented like:
  146.  
  147.     type        size in bits        alignment in bytes
  148.  
  149.     char                8                       1
  150.     short              16                       2
  151.     int                32                       2
  152.     long               32                       2
  153.     all pointers       32                       2
  154.     float(fpu)         32                       2       see below
  155.     double(fpu)        64                       2       see below
  156.  
  157.     Although it would be better to have all 32bit+ types aligned to 4 bytes
  158.     I chose 2 bytes to be compatible with the Amiga system structures which
  159.     unfortunately have longwords aligned to 4n+2-addresses.
  160.  
  161.     The amiga68k code generator at the moment only works on systems
  162.     that store floats and doubles in a similar way (IEEE) like the Amiga.
  163.  
  164.  
  165. SMALL DATA
  166.  
  167.     vbcc can access static data in two ways. By default all such data will
  168.     be accessed with full 32bit addresses (large data model).
  169.     However there is a second way. You can set up an address register (a4)
  170.     to point into your data segment and then address data with a 16bit
  171.     offset through this register.
  172.     The advantages of the small data model are that your program will
  173.     usually be smaller (because the 16bit offsets use less space and no
  174.     relocation information is needed) and faster.
  175.     The disadvantages are that one address register cannot be used by the
  176.     compiler and that you can use it only if all your static data occupies
  177.     less than 64kb. Also you may not mix object modules and libraries that
  178.     have been compiled with different data models (you can call functions
  179.     compiled with large data model from object files compiled with small
  180.     data model, but not vice versa and only functions can be called that
  181.     way - other data cannot be accessed) and you probably have to use
  182.     PhxLnk then.
  183.  
  184.     If you use small data together with functions which are called from
  185.     functions which have not been compiled with vbcc or with the small data
  186.     model then you _must_ define those functions with the __saveds attribute
  187.     or call geta4() as the first statement in your function (do not use
  188.     automatic initializations prior to the call to geta4).
  189.     Note that you must not call geta4() through a function pointer!
  190.  
  191.  
  192. SMALL CODE
  193.  
  194.     If you use the small code model calls to external functions (i.e. from
  195.     libraries or other object files) are done with 16bit offsets over
  196.     the program counter rather than with absolute 32bit addresses.
  197.     The advantage is slightly smaller and faster code.
  198.     The disadvantages are that all the code (including library functions)
  199.     must be small enough and that you may have to use PhxLnk. However
  200.     you can link objects/libraries together if they have been compiled
  201.     with different code models.
  202.  
  203.  
  204. CPUs
  205.  
  206.     At the moment the values of -cpu=n have those effects:
  207.  
  208.     n>=68020:   - 32bit multiplication/division/modulo is done with the
  209.                   mul?.l, div?.l and div?l.l instructions
  210.                 - tst.l ax is used
  211.                 - extb.l dx is used
  212.                 - 16/32bit offsets are used in certain addressing modes
  213.                 - link.l is used
  214.                 - addressing modes with scaling are used
  215.                 - (dx) is used if no address register is available (not yet)
  216.  
  217.     n==68040    - 8bit constants are not copied in data registers
  218.  
  219.  
  220. FPUs
  221.  
  222.     At the moment the values of -fpu=n have those effects:
  223.  
  224.     n>68000:    - floating point calculations are done using the fpu
  225.     n=68040:
  226.     n=68060:    - instructions that have to be emulated on these fpus
  227.                   will not be used; at the moment this only includes
  228.                   the fintrz instruction in case of the 040
  229.  
  230.  
  231. MATH
  232.  
  233.     Integer math hopefully works without problems on all cpus. Long multiply
  234.     on cpus <68020 uses inline routines. This may increase code size a bit,
  235.     but it should be significantly faster, because function call overhead
  236.     is not necessary and the compiler can use the registers which already
  237.     contain the sources and/or need the result. However if anyone really
  238.     wants an option for using library routines for multiply, this can easily
  239.     be implemented. Long division and modulo is handled by calls to library
  240.     functions. At the moment standard library calls with parameter passing
  241.     via stack are used. This is rather slow, but division takes quite some
  242.     time anyway.
  243.     (mult/div/mod with constant powers of two are replaced by corresponding
  244.      bitwise operations (mod only if the other operand is unsigned), but
  245.      sums of powers of two not yet).
  246.  
  247.     If no FPU is specified floating point math is done using the C=
  248.     math libraries. 32 bit IEEE format is used for float and 64 bit IEEE
  249.     for double.
  250.  
  251.     Floating point math is done with the FPU if one is specified (see above).
  252.     Floating point values are kept in registers then and therefore may
  253.     have extended precision sometimes, which is not ANSI compliant (but
  254.     will usually cause no harm). When floating point values are stored in
  255.     memory they use the same IEEE formats as without FPU.
  256.     Float or double return values are passed in fp0.
  257.  
  258.     Note that you must not link object files together if they were not
  259.     compiled with the same -fpu settings and that you have to link with
  260.     the proper math library (see vclib.doc).
  261.  
  262.  
  263. TARGET-SPECIFIC VARIABLE ATTRIBUTES
  264.  
  265.     The m68k-backend offers the following variable attributes:
  266.  
  267.     __saveds:   Load the pointer to the small data segment at
  268.                 function-entry. Applicable only to functions.
  269.  
  270.     __chip:     Place variable in chip-memory. Only applicable on
  271.                 AmigaOS to variables with static storage-duration.
  272.  
  273.     __far:      Do not place this variable in the small-data segment
  274.                 in small-data-mode. No effect in large-data-mode.
  275.                 Only applicable to variables with static storage-
  276.                 duration.
  277.  
  278.     __near:     Currently ignored.
  279.  
  280.  
  281.  
  282. STDARG
  283.  
  284.     A possible <stdarg,h> could look like this:
  285.  
  286.     typedef unsigned char *va_list;
  287.  
  288.     #define va_start(ap, lastarg) ((ap) = (va_list)(&lastarg + 1))
  289.     #define va_arg(ap, type) ((ap) += \
  290.       (sizeof(type)<sizeof(int)?sizeof(int):sizeof(type)), ((type *)(ap))[-1])
  291.     #define va_end(ap) ((ap) = 0L)
  292.  
  293.  
  294. KNOWN PROBLEMS
  295.  
  296.     - Converting floating point values to unsigned integers is not correct
  297.       if the value is >LONG_MAX and code for an FPU is generated.
  298.  
  299.     - The extended precision of the FPU registers can cause problems if
  300.       a program depends on the exact precision. Most programs will not
  301.       have trouble with that, but programs which do exact comparisons
  302.       with floating point types (e.g. to try to calculate the number
  303.       of significant bits) may not work as expected (especially if the
  304.       optimizer was turned on).
  305.  
  306.  
  307. Volker Barthelmann                                      volker@vb.franken.de
  308.  
  309.