This chapter documents the backend for the 6502
processor family.

@section Additional options

This backend provides the following additional options:

@table @option

    @item -c02
    @item -65c02
              Generate code using 65C02 extensions.

    @item -ce02
              Generate code using CSG 65CE02/4510 extensions.

    @item -mega65
              Generate code using the MEGA65 extensions.           

    @item -m65io
              When using the MEGA65 multiplier/divider, assume that the IO area
              is directly accessible to generate smaller and faster code.

    @item -div-bug
              Do not generate code using the MEGA65 divider as this is buggy in
              early versions.

    @item -std-syntax
              Generate code for the std syntax module of vasm rather than
              the default oldstyle syntax module.

    @item -cbmascii
              Convert string-constants and character-constants to CBM ASCII.

    @item -atascii
              Convert string-constants and character-constants to Atari ASCII.

    @item -ieee
              Use 32/64bit IEEE format for floating point rather than wozfp format.

    @item -softstack
              Try to use the hardware stack as little as possible. Use this if your
              hardware stack is overflowing.

    @item -mainargs
              Some targets may need special initializations when using the command
              line arguments to main(). vbcc will emit a call to a library function
              when those are used and @code{-mainargs} is specified.

    @item -no-bank-vars
              Do not automatically handle accesses to banked variables, but only
              function calls. See chapter on banking.

    @item -manual-banking
              Do not automatically handle banking. Useful if you want to use the
              section mapping of the @code{__bank}-attribute or @code{#pragma bank}
              but you prefer handle bank switching yourself.

    @item -avoid-bank-switch
              Prefer calling @code{__bankload/__bankstore} instead of @code{__bankswitch}.
              Useful for banking mechanisms that do not provide quick switching
              of an entire bank (e.g. the C64 REU).

    @item -common-banknr=<n>
              Specify the bank number of the common bank. See chapter on banking. The
              default number is 0.

    @item -large
              Use large memory model. All pointers will be far pointers. A corresponding
              library is required. This feature is experimental.

    @item -glob-acc
              By default, the register allocator will only assign temporary
              variables to the accumulator register or @code{a/x} register pair.
              Usually this reduces necessary storing/loading of the accumulator
              as it is needed during most operations. This option allows the
              register allocator to assign variables with bigger live ranges to
              the accumulator. This option is likely to create worse code in
              most cases. Use only for experimentation.

@end table

@section ABI

    The current version generates assembler output for use with 
    @command{vasm6502_oldstyle} or  @command{vasm6502_std}. 
    The option @command{-opt-branch} is needed.

    The register names provided by this backend are:

@example
        a, sp, r0..r31, btmp0..btmp3
@end example

        @code{a} is the accumulator. It can be used for type @code{char}.

        @code{r0} ... @code{r31} are 8bit variables that can be used for type
        @code{char}. They have to be mapped
        to zero page during linking. The compiler expects registers that can
        be used as register pairs (see below) to be mapped to contiguous
        memory locations. Some library routines may have additional requirements.

        @code{sp} is a 16bit variable that has to be mapped to zero page. It is
        used by the compiler and not available for use. @code{sp} must be
        initialized to a suitable memory area. This stack is used for local variables,
        saved registers etc. The hardware stack is used mainly for return addresses
        and sometimes saved registers.

        @code{btmp0}..@code{btmp3} are 32bit variables. The code generated by vbcc
        does not require them in zero page, but the current library implementation
        expects them to be located to contiguous zero page locations.

        The following register pairs can be used for
        16bit values.

@example
        a/x, r0/r1, r2/r3 ... r30/r31
@end example        

       @code{a/x} can be used for types @code{short} and @code{int}, the other
       register pairs can also be used for pointer types.

        The following register pairs can be used for
        64bit values (IEEE doubles or long long).

@example
        btmp0/btmp1, btmp2/btmp3
@end example         


       Registers @code{a, r0..r15, r28..r31, btmp0..btmp3} are volatile
       (i.e. they can be destroyed in function calls). @code{r16..r27} are
       preserved across function calls.   

       @code{r0..r7} are used for passing function arguments of type
       @code{char, short, int} and pointer types. @code{btmp0..btmp3} are
       used for passing arguments of type @code{long, long long, float, double,
       long double} and far pointers. All other types are passed on the stack.

       For functions with a variable-argument-list, arguments that are part
       of the variable-argument-list are always passed on the stack. It is
       therefore required that a prototype is in scope when calling such functions
       (as required by C).

       Scalar types are returned as follows:
@example
    type        registers

    char        a
    short       a/x
    int         a/x
    long        btmp0
    long long   n/a
    pointers    a/x
    far-pointer btmp0
    float       btmp0
    double      btmp0 or btmp0/btmp1 (IEEE)
    long double btmp0 or btmp0/btmp1 (IEEE)
@end example

       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.

The basic data types are represented like this:

@example
    type        size in bits        alignment in bytes

    char                8                       1
    short              16                       1
    int                16                       1
    long               32                       1
    long long          64                       1       (currently not supported)
    near pointers      16                       1
    far pointers       24                       1       
    float              32                       1       see below
    double             32/64                    1       see below
    long double        32/64                    1       see below
@end example


@section Math


    For certain operations @code{vbcc} will emit calls to routines that have
    to be provided by a library.
    For integer code, the following operations are handled by library routines
    (some special cases involving constants may be handled by inline code).

@example
     __mulint16                 16x16=>16 multiplication
     __mulint32                 32x32=>32 multiplication
     __divint16                 16x16=>16 signed division
     __divint32                 32x32=>32 signed division
     __divuint16                16x16=>16 unsigned division
     __divuint32                32x32=>32 unsigned division
     __modint16                 16x16=>16 signed modulo
     __modint32                 32x32=>32 signed modulo
     __moduint16                16x16=>16 unsigned modulo
     __moduint32                32x32=>32 unsigned modulo
@end example

@subsection Floating Point

    By default, all floating point types are implemented as 32bit values.
    The format used by the floating point routines published by Roy Rankin
    and Steve Wozniak is used. While this does work for many use cases, it
    is not fully C compliant by any means. Calculation of constants in the
    compiler is not done in that format. Therefore, the results of
    calculations done at compile-time may be different from those at run-time.
    The corresponding math library must be linked using @code{-lm}.

    As an alternative, @code{vbcc} can use IEEE format by specifying
    @code{-ieee}. This will solve the problems mentioned above and provide
    accurate results using the SANE floating point environment. However,
    these routines are slower and much bigger. Also, you may have to clarify
    their legal status before using them. The IEEE routines will likely not
    work when running from ROM.

    In addition to @code{-ieee}, the SANE library has to be linker using
    @code{-lmieee}.

    When using floating point, the following library routines are needed
    (without @code{-ieee}):

@example
    __addflt32                 floating point addition
    __subflt32                 floating point subtraction
    __mulflt32                 floating point multiplication
    __divflt32                 floating point division
    __negflt32                 floating point negation (-x)
    __cmpsflt32                floating point comparison
                               (sets @code{a} to pos., neg. or zero, depending on
                               the comparison result)
    __sint16toflt32            convert signed 16bit integer to floating point
    __uint16toflt32            convert unsigned 16bit integer to floating point
    __sint32toflt32            convert signed 32bit integer to floating point
    __uint32toflt32            convert unsigned 32bit integer to floating point
    __flt32tosint16            convert floating point value to signed 16bit integer
    __flt32touint16            convert floating point value to unsigned 16bit integer
    __flt32tosint32            convert floating point value to signed 32bit integer
    __flt32touint32            convert floating point value to unsigned 32bit integer
@end example

     Further math library functions may be needed by user code or the C library.


@section Target-Specific Variable Attributes

    This backend offers the following variable attributes:

@table @code
    @item __interrupt
          Used for writing interrupt handlers. All used registers
          (including volatiles and accumulator) are saved/restored and
          @code{rti} is used to leave the function. Also, the user stack
          pointer is set to @code{__isrstack}. This value for the interrupt
          stack has to be provided e.g. by the linker script.

    @item __zpage
              Place variable in section @code{zpage} and instruct @code{vbcc}
              to use it with zero-page addressing.

    @item __nocpr
          Turn off code compression for this function even if @code{-size} is used.
          Useful for time-critical functions.

    @item __bank(<n>)
          Place the variable/function in bank n. See chapter on banking for details.

@end table

@section Target-Specific #pragmas

    This backend offers the following #pragmas

@table @code
    @item #pragma section <sec>
              The following functions and variables are placed in section <sec>.

    @item #pragma section default
              The following functions and variables are placed in default sections.

    @item #pragma bank <n>
              The following functions and variables are placed in bank <n>. See the
              chapter on banking for details.

    @item #pragma bank -1
              The following functions and variables are placed in the default bank. See the
              chapter on banking for details.

@end table


@section Predefined Macros

        This backend defines the following macros:

@table @code
        @item __6502__
        
        @item __SIZE_T_INT

@end table


@section Stack

    Local variables and function arguments are put on the user stack. It
    can be up to 64KB, but accessing variables outside the lower 256 bytes
    is significantly slower. @code{vbcc} will put small variables on lower
    offsets to increase the number of variables that can be addressed fast.
    However, accessing the stack is always rather slow on the 6502.

    The stack pointer is adjusted once during function entry/exit to avoid
    multiple costly adjustments to the stack pointer.

    Variable-length-arrays as specified in c99 should be fully supported.


@section Banking

    Many 6502 systems offer/need different banking mechanisms. vbcc offers different
    levels of support for those schemes. Depending on the target integration, more
    or less support is offered.

@subsection Manual Banking

    Banking can usually be implemented manually if there is no suitable target
    integration or if manual optimization is preferred.

    For manual banking, functions and/or data can be mapped to sections using
    the @code{section} attribute or the @code{#pragma section} directive. Note that
    string constants will be mapped to banked memory only when using the @code{#pragma}
    approach.

    After placing the objects in suitable sections, they have to be located using a
    linker command file. See the documentation on vlink. Switching between banks has
    to done manually in a system-specific way.

    If initialized variables are mapped into banked sections, be aware that you may have
    to provide means to initialize them on startup. It is probably not handled by
    startup code for non-banked systems. This is not relevant for systems that only
    provide banked ROM.
    

@subsection Automated Banking

    If a suitable target integration is available, vbcc is able to automatically
    handle bank switching.

@subsubsection Memory Model

    vbcc assumes a memory model which provides non-banked
    memory for code and data that is always visible. Additionally there can be a
    number of up to 255 memory banks, one of which can be visible at a time.

    If several banks can be visible at the same time, this will also work, but vbcc
    does not make use of this feature.

@subsubsection Mapping

    Code/data can be put into banks using the @code{bank}-attribute or 
    @code{#pragma bank}. Note that string constants will be mapped to banked memory only
    when using the @code{#pragma} approach. Code/data not mapped to a bank will be
    mapped to the always visible non-banked area.

    Banked objects will be mapped to sections suffixed with the bank number, e.g. in

@example
__bank(0) int i = 1;
__bank(1) void f() { }
@end example

    @code{i} will be put into section @code{data0} and @code{f} will be put
    into section @code{text1}.

@subsubsection Bank Switching

    vbcc will try to determine when a bank switch has to
    be made and it will call library functions to map in the required data. This
    requires that when accessing an object, vbcc has to know which bank the object is
    assigned to. Therefore a declaration specifying the correct bank number (either
    using the @code{__bank()}-attribute or @code{#pragma bank}). If an object is
    accessed which has not been declared with a bank number, it is assumed that it
    can be accessed without bank switching.

@subsubsection Far Pointers

    When accessing an object through a normal pointer, the bank number is not known.
    All accesses through normal pointers assume that the target is always visible.
    For all other cases, far-ointers have to be used. Far-pointers contain the bank number
    as additional information, resulting in a size of 3 bytes.

    They are declared using the @code{__far}-qualifier. @code{__far} is used like a type
    qualifier, similar to @code{const}.

@example
       __bank(0) i0;
       __bank(1) i1;
       __far int *fp;
       ...

       if(..)
         fp = &i0;
       else
         fp = &i1;
@end example
    
    Converting a far-pointer to a normal pointer will loose the bank information.
    Converting a normal pointer to a far-pointer will insert the bank number of the current
    function. Care must be taken not to loose bank information when working with
    pointers.

@subsubsection Performance Considerations

   Accessing objects through bank switching generates much slower and larger code than
   direct accesses. Therefore it is crucial to organize your objects in a way that 
   reduces task switches as much as possible. Following is a list of hints and
   explanations.

@itemize
@item Using far pointers will always incur overhead. Try to use them only when
      necessary.

@item Accessing objects from the non-banked area is always fast (unless done through
      far-pointers).

@item Accessing objects from the same bank the function is mapped to is usually fast
      (unless done through far-pointers).

@item Accessing banked objects from non-banked code is usually faster than accessing
      them from banked code in another bank.

@item Calling functions in another bank is a reasonably small overhead on systems with a
      fast bank switch. It can be much more overhead on RAM expansions that have to
      copy code.

@item Be careful when using function inlining. Inlined code will be executed in
      the bank of the caller.
@end itemize

In general, try to reduce cross-bank accesses and far-pointer usage as much as possible.
For best performance you can always only use the @code{section}-features to map everything
and handle all bank-switching yourself.

@subsubsection Library

To use the automated bank switching, a series of library functions must be available
(TODO: add more detailed information, may change):


@table @code
@item ___bankswitch
      Make the bank in @code{y} accessible.

@item ___bankjsr
      Call the function pointer @code{r30/r31} in bank @code{y}. Return to the caller
      in bank @code{a}.

@item ___bankload<n> (n=1,2,3,4,8)
      Copy <n> bytes from @code{r30/r31} in bank @code{y} to non-banked variable
      @code{___bankv} with offset @code{x}. Caller bank in @code{a}.

@item ___bankstore<n> (n=1,2,3,4,8)
      Copy <n> bytes from non-banked variable @code{___bankv} with offset @code{x} to
      @code{r30/r31} in bank @code{y}. Caller bank in @code{a}.

@item ___bankcopy
      Copy @code{___bankcopy_len/___bankcopy_len+1} bytes from @code{r28/r29} in bank @code{y} to
      @code{r30/r31} in bank @code{x}. Caller bank in @code{a}.
@end table


@section Debugging

    The 6502 backend has some limited support for debugging.

    When using vlink, the @code{-vicelabels} options can be used to output symbol
    values in a format that can be read by the vice emulator/debugger.

    With the @code{-g} option, line numbers and file names of source code will
    be added to the assembly output. Using some tools, it should be possible to
    create a mixed C/assembly file for inspection.
    Depending on the optimization level, the
    results may be more or less usable, see section Debugging Optimized Code.
    Note that the added comments will affect the assembly peephole
    optimizer, resulting in worse code than without @code{-g}.
    

@section Code compressor

    The @code{vcpr6502} code compressor supports the 6502 target. It should
    be called automatically on higher optimization levels when using the
    frontend @code{vc}. As the code will be slowed down when using compression,
    the 6502 backend will only enable compression when using the @code{-size}
    option.

    TODO: manual overriding


@section Known problems

@itemize @minus
    @item @code{long long} not yet supported

    @item return value of cross-bank function calls may not work

    @item banking not tested very much
    

@end itemize