<article>
<title>Defining a Custom cc65 Target
<author>Bruce Reidenbach
-<date>2010-02-22
+<date>2015-03-13
<abstract>
This section provides step-by-step instructions on how to use the cc65
<tscreen><code>
SEGMENTS {
- ZEROPAGE: load = ZP, type = zp, define = yes;
- DATA: load = ROM, type = rw, define = yes, run = RAM;
- BSS: load = RAM, type = bss, define = yes;
- HEAP: load = RAM, type = bss, optional = yes;
- STARTUP: load = ROM, type = ro;
- INIT: load = ROM, type = ro, optional = yes;
- CODE: load = ROM, type = ro;
- RODATA: load = ROM, type = ro;
- VECTORS: load = ROM, type = ro, start = $FFFA;
+ ZEROPAGE: load = ZP, type = zp, define = yes;
+ DATA: load = ROM, type = rw, define = yes, run = RAM;
+ BSS: load = RAM, type = bss, define = yes;
+ HEAP: load = RAM, type = bss, optional = yes;
+ STARTUP: load = ROM, type = ro;
+ ONCE: load = ROM, type = ro, optional = yes;
+ CODE: load = ROM, type = ro;
+ RODATA: load = ROM, type = ro;
+ VECTORS: load = ROM, type = ro, start = $FFFA;
}
</code></tscreen>
<p><tt> BSS: </tt>Uninitialized data stored in RAM (used for variable storage)
<p><tt> HEAP: </tt>Uninitialized C-level heap storage in RAM, optional
<p><tt> STARTUP: </tt>The program initialization code, stored in ROM
-<p><tt> INIT: </tt>The code needed to initialize the system, stored in ROM
+<p><tt> ONCE: </tt>The code run once to initialize the system, stored in ROM
<p><tt> CODE: </tt>The program code, stored in ROM
<p><tt> RODATA: </tt>Initialized data that cannot be modified by the program, stored in ROM
<p><tt> VECTORS: </tt>The interrupt vector table, stored in ROM at location $FFFA
to determine how to pass the C arguments to the assembly language
routine. The cc65 toolset allows the user to specify whether the data
is passed to a subroutine via the stack or by the processor registers by
-using the <tt>__fastcall__</tt> function declaration (note that there
-are two underscore characters in front of and two behind the
-<tt>fastcall</tt> declaration). When <tt>__fastcall__</tt> is
-specified, the rightmost argument in the function call is passed to the
+using the <tt/__fastcall__/ and <tt/__cdecl__/ function qualifiers (note that
+there are two underscore characters in front of and two behind each
+qualifier). <tt/__fastcall__/ is the default. When <tt/__cdecl__/ <em/isn't/
+specified, and the function isn't variadic (i.e., its prototype doesn't have
+an ellipsis), the rightmost argument in the function call is passed to the
subroutine using the 6502 registers instead of the stack. Note that if
there is only one argument in the function call, the execution overhead
required by the stack interface routines is completely avoided.
-Without <tt>__fastcall__</tt>, the argument is loaded in the A and X
+With <tt/__cdecl__</tt>, the last argument is loaded into the A and X
registers and then pushed onto the stack via a call to <tt>pushax</tt>.
The first thing the subroutine does is retrieve the argument from the
stack via a call to <tt>ldax0sp</tt>, which copies the values into the A
jmp incsp2 ; Pop A and X from the stack (includes return)
</verb></tscreen>
-If <tt>__fastcall__</tt> is specified, the argument is loaded into the A
+If <tt/__cdecl__/ isn't specified, then the argument is loaded into the A
and X registers as before, but the subroutine is then called
immediately. The subroutine does not need to retrieve the argument
since the value is already available in the A and X registers.