This chapter documents the backend for the M68k and Coldfire
processor families.

@section Additional options

This backend provides the following additional options:

@table @option

    @item -a2scratch
              Allow using @code{A2} as scratch register.

    @item -amiga-softfloat
              Call AmigaOS MathIEEE library functions via direct inline
              code, instead of callling stub routines from @file{mieee.lib}.
              It still requires that you either link with @file{mieee.lib} or
              define @code{MathIeeeSingBasBase}, @code{MathIeeeDoubBasBase}
              and @code{MathIeeeDoubTransBase} yourself.

    @item -conservative-sr
              Restrict strength-reduction. Experimental.

    @item -const-in-data
              By default constant data will be placed in the code
              section (and therefore is accessible with faster pc-relative
              addressing modes). Using this option it will be placed in the
              data section.

              This could e.g. be useful if you want to use small data and
              small code, but your code gets too big with all the constant
              data.

              Note that on operating systems with memory protection this
              option will disable write-protection of constant data.

    @item -cpu=n
              Generate code for cpu n (e.g. @option{-cpu=68020}),
              defaults to 68000.

    @item -d2scratch
              Allow using @code{D2} as scratch register.

    @item -fastcall
              Pass function arguments in volatile registers, when possible.

    @item -fp2scratch
              Allow using @code{FP2} as scratch register.

    @item -fpu=n
              Generate code for fpu n (e.g. @option{-fpu=68881}), default: 0.

    @item -gas
              Create output suitable for the GNU assembler.

    @item -hunkdebug
              When creating debug-output (@option{-g} option) create
              Amiga debug hunks rather than DWARF2.
              Does not work with @option{-gas}.

    @item -no-delayed-popping
              By default arguments of function calls are not always popped
              from the stack immediately after the call, so that the
              arguments of several calls may be popped at once.
              With this option @command{vbcc} can be forced to pop them after every
              function call.
              This may simplify debugging and reduce the
              stack size needed by the compiled program.

    @item -no-fp-return

              Do not return floats and doubles in floating-point registers
              even if code for an fpu is generated.

    @item -no-intz
              When generating code for FPU do quick&dirty conversions
              from floating-point to integer. The code may be somewhat
              faster but will not correctly round to zero.
              Only use it if you know what you are doing.

    @item -no-mreg-return
              Do not use multiple registers to return types that do not
              fit into a single register. This is mainly for backwards
              compatibility with certain libraries.

    @item -no-peephole
              Do not perform peephole-optimizations.

    @item -no-reserve-regs
              Do not reserve temporary registers for the backend. Can lead to
              worse code generation.

    @item -old-softfloat
              Use old libcall mechanism for software floating point.
              Should not be used, will usually generate worse code.

    @item -old-libcalls
              Use old libcall mechanism for (some) integer support routines.
              Should not be used, will usually generate worse code.

    @item -phxass
              Generate assembly output for the PhxAss assembler.

    @item -prof
              Insert code for profiling.

    @item -sc
              Use small code model (see below).

    @item -sd
              Use small data model (see below).

    @item -use-commons
              Use real common symbols instead of bss symbols for
              non-initialized external variables.

    @item -use-framepointer
              By default automatic variables are addressed through a7
              instead of a5. This generates slightly better code, because
              the function entry and exit overhead is reduced and a5 can be
              used as register variable etc.

              However this may be a bit confusing when debugging and you
              can force @command{vbcc} to use a5 as a fixed framepointer.


@end table

@section ABI

    The current version generates assembler output for use with the
    @command{vasmm68k_mot}. Most peephole optimizations are done by the
    assembler so @command{vbcc} only does some that the assembler cannot make.
    The generated executables will probably only work with OS2.0 or higher.

    With @option{-gas} assembler output suitable for the GNU assembler is generated
    (the version must understand the Motorola syntax - some old ones do not).
    The output is only slightly modified from the @command{vasm}-output and will
    therefore result in worse code on @command{gas}.

    The register names provided by this backend are:

@example
         a0,  a1,  a2,  a3,  a4,  a5,  a6,  a7
         d0,  d1,  d2,  d3,  d4,  d5,  d6,  d7
        fp0, fp1, fp2, fp3, fp4, fp5, fp6, fp7
@end example

        The registers @code{a0} - @code{a7} are supported to hold pointer
        types. @code{d0} - @code{d7} can be used for integers types
        excluding @code{long long}, pointers and @code{float} if no
        FPU code is generated. @code{fp0} - @code{fp7} can be used for
        all floating point types if FPU code is generated.

        Additionally the following register pairs can be used for
        @code{long long}:

@example
        d0/d1, d2/d3, d4/d5, d6/d7
@end example        

    The registers @code{d0, d1, a0, a1, fp0} and @code{fp1}  are used as scratch registers
    (i.e. they can be destroyed in function calls), all other registers are
    preserved.

        By default, all function arguments are passed on the stack.

    All scalar types up to 4 bytes are returned in register @code{d0},
        @code{long long} is returned in @code{d0/d1}.
        If compiled for FPU, floating point values are returned in
    @code{fp0} unless @option{-no-fpreturn} is specified.
    Types which are 8, 12 or 16 bytes large will be returned in several
    registers (@code{d0/d1/a0/a1}) unless @option{-no-mreg-return} is specified.
    All other types are returned by passing the function the address
    of the result as a hidden argument - such a function must not be called
    without a proper declaration in scope.

    Objects which have been compiled with different settings must not be
        linked together.

        @code{a7} is used as stack pointer. If @option{-sd} is used,
        @code{a4} will be used as small data pointer. If 
        @option{-use-framepointer} is used, @code{a5} will be used as
        frame pointer. All other registers will be used by the
        register allocator and can be used for register parameters.

        The size of the stack frame is limited to 32KB for early members
        of the 68000 family prior to 68020.


The basic data types are represented like:

@example
    type        size in bits        alignment in bytes

    char                8                       1
    short              16                       2
    int                32                       2
    long               32                       2
    long long          64                       2
    all pointers       32                       2
    float(fpu)         32                       2       see below
    double(fpu)        64                       2       see below
    long double(fpu)   64                       2       see below
@end example


@section Small data

    @command{vbcc} can access static data in two ways. By default all such data will
    be accessed with full 32bit addresses (large data model).
    However there is a second way. You can set up an address register 
        (@code{a4})
    to point into the data segment and then address data with a 16bit
    offset through this register.

    The advantages of the small data model are that the program will
    usually be smaller (because the 16bit offsets use less space and no
    relocation information is needed) and faster.

    The disadvantages are that one address register cannot be used by the
    compiler and that it can only be used if all static data occupies
    less than 64kb. Also object modules and libraries that
    have been compiled with different data models must not be mixed
    (it is possible to call functions
    compiled with large data model from object files compiled with small
    data model, but not vice versa and only functions can be called that
    way - other data cannot be accessed).

    If small data is used with functions which are called from
    functions which have not been compiled with @command{vbcc} or without the small data
    model then those functions must be declared with the @code{__saveds} attribute
    or call @code{geta4()} as the first statement (do not use
    automatic initializations prior to the call to @code{geta4}).
    Note that @code{geta4()} must not be called through a function pointer!


@section Small code

    In the small code model calls to external functions (i.e. from
    libraries or other object files) are done with 16bit offsets through
    the program counter rather than with absolute 32bit addresses.

    The advantage is slightly smaller and faster code.
    The disadvantages are that all the code (including library functions)
    must be small enough. Objects/libraries can be linked together if they
    have been compiled with different code models.


@section CPUs

    The values of @option{-cpu=n} have those effects:

@table @option

    @item n<68000     
        Code for the Coldfire family is generated.

    @item n>=68000    
        Code for the 68k family is generated.

    @item n>=68020
@itemize @minus
   @item 32bit multiplication/division/modulo is done with the
                  mul?.l, div?.l and div?l.l instructions.
   @item tst.l ax is used.
   @item extb.l dx is used.
   @item 16/32bit offsets are used in certain addressing modes.
   @item link.l is used.
   @item Addressing modes with scaling are used.
@end itemize

    @item n==68040
@itemize @minus
   @item 8bit constants are not copied in data registers.
   @item Static memory is not subject to common subexpression elimination.
@end itemize

@end table


@section FPUs

    At the moment the values of -fpu=n have those effects:

@table @option
    @item n>68000    
        Floating point calculations are done using the FPU.
    @item n=68040
    @itemx n=68060    
        Instructions that have to be emulated on these FPUs
                  will not be used; at the moment this only includes
                  the @code{fintrz} instruction in case of the 040.
@end table

@section Math

    Long multiply
    on CPUs <68020 uses inline routines. This may increase code size a bit,
    but it should be significantly faster, because function call overhead
    is not necessary. 
    Long division and modulo is handled by calls to library
    functions.
    (Some operations involving constants (e.g. powers of two) are always
    implemented by more efficient inline code.)

    If no FPU is specified floating point math is done using
    math libraries. 32bit IEEE format is used for float and 64bit IEEE
    for double and long double.

    If floating point math is done with the FPU
    floating point values are kept in registers and therefore may
    have extended precision sometimes. This is not ANSI compliant but
    will usually cause no harm. When floating point values are stored in
    memory they use the same IEEE formats as without FPU.
    Return values are passed in @code{fp0}.

    Note that you must not link object files together if they were not
    compiled with the same @code{-fpu} settings and that
    a proper math library must be linked.


@section Target-Specific Variable Attributes

    This backend offers the following variable attributes:

@table @code
    @item __amigainterrupt
                Used to write interrupt-handlers for AmigaOS. Stack-checking
                for a function with this attribute will be disabled and if a value
                is returned in d0, the
                condition codes will be set accordingly.

    @item __chip
              Place variable in chip-memory. Only applicable on
                 AmigaOS to variables with static storage-duration.

    @item __far
               Do not place this variable in the small-data segment
                 in small data mode. No effect in large data mode.
                 Only applicable to variables with static
                storage-duration.

    @item __interrupt
                 This is used to declare interrupt-handlers. The
                 function using this attribute will save all registers
                 it destroys (including scratch-registers) and return
                 with @code{rte} rather than @code{rts}.

    @item __near
              Currently ignored.

    @item __regargs
            Declare function to use the @option{-fastcall} ABI. The
            first arguments are passed in volatile registers.

    @item __saveds
            Load the pointer to the small data segment at
                 function-entry. Applicable only to functions.

    @item __section(<string-literal>)
                 Places the variable/function in a section named
                 according to the argument.

    @item __stdargs
            Declare function to use the standard ABI (default),
            which passes all arguments on the stack.
@end table

@section Target-specific pragmas

    This backend offers the following #pragmas:

@table @code

    @item #pragma stdargs-on
          Automatically declare the following functions with the
          @code{__stdargs} attribute.

    @item #pragma stdargs-off
          Stop automatically declaring the following functions with the
          @code{__stdargs} attribute.

@end table

@section Predefined Macros

        This backend defines the following macros:

@table @code
        @item __AMIGADATE__
                This is set to current date as @code{"(DD.MM.YYYY)"},
                useful with version strings.

        @item __COLDFIRE
                (If a Coldfire CPU is selected.)
        
        @item __INTSIZE
                Is set to the size of the @code{int} type.
                Either 16 (vbccm68ks) or 32 (vbccm68k).

        @item __M680x0
                (Depending on the settings of @option{-cpu}, e.g.
                @code{__M68020}.)

        @item __M68881 
                (If @option{-fpu=68881} is selected.)

        @item __M68882
                (If code for another FPU is selected;
                @option{-fpu=68040} or @option{-fpu=68060} will
                set @code{__M68882}.)

        @item __M68K__

        @item __SMALL_DATA__
                (If @option{-sd} is selected to enable small data.)
@end table


@section Stack

    If the @option{-stack-check} option is used, every function-prologue will
    call the function @code{__stack_check} with the stacksize needed by the
    current function on the stack. This function has to consider its own
    stacksize and must restore all registers.

    If the compiler is able to calculate the maximum stack-size of a
    function including all callees, it will add a comment in the
    generated assembly-output (subject to change to labels).


@section Stdarg

    A possible @file{<stdarg.h>} could look like this:

@example

typedef unsigned char *va_list;

#define __va_align(type) (__alignof(type)>=4?__alignof(type):4)

#define __va_do_align(vl,type) ((vl)=(char *)((((unsigned int)(vl))+__va_align(type)-1)/__va_align(type)*__va_align(type)))

#define __va_mem(vl,type) (__va_do_align((vl),type),(vl)+=sizeof(type),((type*)(vl))[-1])

#define va_start(ap, lastarg) ((ap)=(va_list)(&lastarg+1))
 
#define va_arg(vl,type) __va_mem(vl,type)
 
#define va_end(vl) ((vl)=0)

#define va_copy(new,old) ((new)=(old))

#endif


@end example

@section Known problems

@itemize @minus
    @item The extended precision of the FPU registers can cause problems if
      a program depends on the exact precision. Most programs will not
      have trouble with that, but programs which do exact comparisons
      with floating point types (e.g. to try to calculate the number
      of significant bits) may not work as expected (especially if the
      optimizer was turned on).
@end itemize