PulkoMandy | 17fc759 | 2022-07-28 18:27:54 +0200 | [diff] [blame] | 1 | This chapter documents the backend for the 6502 |
| 2 | processor family. |
| 3 | |
| 4 | @section Additional options |
| 5 | |
| 6 | This backend provides the following additional options: |
| 7 | |
| 8 | @table @option |
| 9 | |
| 10 | @item -c02 |
| 11 | @item -65c02 |
| 12 | Generate code using 65C02 extensions. |
| 13 | |
| 14 | @item -ce02 |
| 15 | Generate code using CSG 65CE02/4510 extensions. |
| 16 | |
| 17 | @item -mega65 |
| 18 | Generate code using the MEGA65 extensions. |
| 19 | |
| 20 | @item -m65io |
| 21 | When using the MEGA65 multiplier/divider, assume that the IO area |
| 22 | is directly accessible to generate smaller and faster code. |
| 23 | |
| 24 | @item -div-bug |
| 25 | Do not generate code using the MEGA65 divider as this is buggy in |
| 26 | early versions. |
| 27 | |
| 28 | @item -std-syntax |
| 29 | Generate code for the std syntax module of vasm rather than |
| 30 | the default oldstyle syntax module. |
| 31 | |
| 32 | @item -cbmascii |
| 33 | Convert string-constants and character-constants to CBM ASCII. |
| 34 | |
| 35 | @item -atascii |
| 36 | Convert string-constants and character-constants to Atari ASCII. |
| 37 | |
| 38 | @item -ieee |
| 39 | Use 32/64bit IEEE format for floating point rather than wozfp format. |
| 40 | |
| 41 | @item -softstack |
| 42 | Try to use the hardware stack as little as possible. Use this if your |
| 43 | hardware stack is overflowing. |
| 44 | |
| 45 | @item -mainargs |
| 46 | Some targets may need special initializations when using the command |
| 47 | line arguments to main(). vbcc will emit a call to a library function |
| 48 | when those are used and @code{-mainargs} is specified. |
| 49 | |
| 50 | @item -no-bank-vars |
| 51 | Do not automatically handle accesses to banked variables, but only |
| 52 | function calls. See chapter on banking. |
| 53 | |
| 54 | @item -manual-banking |
| 55 | Do not automatically handle banking. Useful if you want to use the |
| 56 | section mapping of the @code{__bank}-attribute or @code{#pragma bank} |
| 57 | but you prefer handle bank switching yourself. |
| 58 | |
| 59 | @item -avoid-bank-switch |
| 60 | Prefer calling @code{__bankload/__bankstore} instead of @code{__bankswitch}. |
| 61 | Useful for banking mechanisms that do not provide quick switching |
| 62 | of an entire bank (e.g. the C64 REU). |
| 63 | |
| 64 | @item -common-banknr=<n> |
| 65 | Specify the bank number of the common bank. See chapter on banking. The |
| 66 | default number is 0. |
| 67 | |
| 68 | @item -large |
| 69 | Use large memory model. All pointers will be far pointers. A corresponding |
| 70 | library is required. This feature is experimental. |
| 71 | |
| 72 | @item -glob-acc |
| 73 | By default, the register allocator will only assign temporary |
| 74 | variables to the accumulator register or @code{a/x} register pair. |
| 75 | Usually this reduces necessary storing/loading of the accumulator |
| 76 | as it is needed during most operations. This option allows the |
| 77 | register allocator to assign variables with bigger live ranges to |
| 78 | the accumulator. This option is likely to create worse code in |
| 79 | most cases. Use only for experimentation. |
| 80 | |
| 81 | @end table |
| 82 | |
| 83 | @section ABI |
| 84 | |
| 85 | The current version generates assembler output for use with |
| 86 | @command{vasm6502_oldstyle} or @command{vasm6502_std}. |
| 87 | The option @command{-opt-branch} is needed. |
| 88 | |
| 89 | The register names provided by this backend are: |
| 90 | |
| 91 | @example |
| 92 | a, sp, r0..r31, btmp0..btmp3 |
| 93 | @end example |
| 94 | |
| 95 | @code{a} is the accumulator. It can be used for type @code{char}. |
| 96 | |
| 97 | @code{r0} ... @code{r31} are 8bit variables that can be used for type |
| 98 | @code{char}. They have to be mapped |
| 99 | to zero page during linking. The compiler expects registers that can |
| 100 | be used as register pairs (see below) to be mapped to contiguous |
| 101 | memory locations. Some library routines may have additional requirements. |
| 102 | |
| 103 | @code{sp} is a 16bit variable that has to be mapped to zero page. It is |
| 104 | used by the compiler and not available for use. @code{sp} must be |
| 105 | initialized to a suitable memory area. This stack is used for local variables, |
| 106 | saved registers etc. The hardware stack is used mainly for return addresses |
| 107 | and sometimes saved registers. |
| 108 | |
| 109 | @code{btmp0}..@code{btmp3} are 32bit variables. The code generated by vbcc |
| 110 | does not require them in zero page, but the current library implementation |
| 111 | expects them to be located to contiguous zero page locations. |
| 112 | |
| 113 | The following register pairs can be used for |
| 114 | 16bit values. |
| 115 | |
| 116 | @example |
| 117 | a/x, r0/r1, r2/r3 ... r30/r31 |
| 118 | @end example |
| 119 | |
| 120 | @code{a/x} can be used for types @code{short} and @code{int}, the other |
| 121 | register pairs can also be used for pointer types. |
| 122 | |
| 123 | The following register pairs can be used for |
| 124 | 64bit values (IEEE doubles or long long). |
| 125 | |
| 126 | @example |
| 127 | btmp0/btmp1, btmp2/btmp3 |
| 128 | @end example |
| 129 | |
| 130 | |
| 131 | Registers @code{a, r0..r15, r28..r31, btmp0..btmp3} are volatile |
| 132 | (i.e. they can be destroyed in function calls). @code{r16..r27} are |
| 133 | preserved across function calls. |
| 134 | |
| 135 | @code{r0..r7} are used for passing function arguments of type |
| 136 | @code{char, short, int} and pointer types. @code{btmp0..btmp3} are |
| 137 | used for passing arguments of type @code{long, long long, float, double, |
| 138 | long double} and far pointers. All other types are passed on the stack. |
| 139 | |
| 140 | For functions with a variable-argument-list, arguments that are part |
| 141 | of the variable-argument-list are always passed on the stack. It is |
| 142 | therefore required that a prototype is in scope when calling such functions |
| 143 | (as required by C). |
| 144 | |
| 145 | Scalar types are returned as follows: |
| 146 | @example |
| 147 | type registers |
| 148 | |
| 149 | char a |
| 150 | short a/x |
| 151 | int a/x |
| 152 | long btmp0 |
| 153 | long long n/a |
| 154 | pointers a/x |
| 155 | far-pointer btmp0 |
| 156 | float btmp0 |
| 157 | double btmp0 or btmp0/btmp1 (IEEE) |
| 158 | long double btmp0 or btmp0/btmp1 (IEEE) |
| 159 | @end example |
| 160 | |
| 161 | All other types are returned by passing the function the address |
| 162 | of the result as a hidden argument - such a function must not be called |
| 163 | without a proper declaration in scope. |
| 164 | |
| 165 | The basic data types are represented like this: |
| 166 | |
| 167 | @example |
| 168 | type size in bits alignment in bytes |
| 169 | |
| 170 | char 8 1 |
| 171 | short 16 1 |
| 172 | int 16 1 |
| 173 | long 32 1 |
| 174 | long long 64 1 (currently not supported) |
| 175 | near pointers 16 1 |
| 176 | far pointers 24 1 |
| 177 | float 32 1 see below |
| 178 | double 32/64 1 see below |
| 179 | long double 32/64 1 see below |
| 180 | @end example |
| 181 | |
| 182 | |
| 183 | @section Math |
| 184 | |
| 185 | |
| 186 | For certain operations @code{vbcc} will emit calls to routines that have |
| 187 | to be provided by a library. |
| 188 | For integer code, the following operations are handled by library routines |
| 189 | (some special cases involving constants may be handled by inline code). |
| 190 | |
| 191 | @example |
| 192 | __mulint16 16x16=>16 multiplication |
| 193 | __mulint32 32x32=>32 multiplication |
| 194 | __divint16 16x16=>16 signed division |
| 195 | __divint32 32x32=>32 signed division |
| 196 | __divuint16 16x16=>16 unsigned division |
| 197 | __divuint32 32x32=>32 unsigned division |
| 198 | __modint16 16x16=>16 signed modulo |
| 199 | __modint32 32x32=>32 signed modulo |
| 200 | __moduint16 16x16=>16 unsigned modulo |
| 201 | __moduint32 32x32=>32 unsigned modulo |
| 202 | @end example |
| 203 | |
| 204 | @subsection Floating Point |
| 205 | |
| 206 | By default, all floating point types are implemented as 32bit values. |
| 207 | The format used by the floating point routines published by Roy Rankin |
| 208 | and Steve Wozniak is used. While this does work for many use cases, it |
| 209 | is not fully C compliant by any means. Calculation of constants in the |
| 210 | compiler is not done in that format. Therefore, the results of |
| 211 | calculations done at compile-time may be different from those at run-time. |
| 212 | The corresponding math library must be linked using @code{-lm}. |
| 213 | |
| 214 | As an alternative, @code{vbcc} can use IEEE format by specifying |
| 215 | @code{-ieee}. This will solve the problems mentioned above and provide |
| 216 | accurate results using the SANE floating point environment. However, |
| 217 | these routines are slower and much bigger. Also, you may have to clarify |
| 218 | their legal status before using them. The IEEE routines will likely not |
| 219 | work when running from ROM. |
| 220 | |
| 221 | In addition to @code{-ieee}, the SANE library has to be linker using |
| 222 | @code{-lmieee}. |
| 223 | |
| 224 | When using floating point, the following library routines are needed |
| 225 | (without @code{-ieee}): |
| 226 | |
| 227 | @example |
| 228 | __addflt32 floating point addition |
| 229 | __subflt32 floating point subtraction |
| 230 | __mulflt32 floating point multiplication |
| 231 | __divflt32 floating point division |
| 232 | __negflt32 floating point negation (-x) |
| 233 | __cmpsflt32 floating point comparison |
| 234 | (sets @code{a} to pos., neg. or zero, depending on |
| 235 | the comparison result) |
| 236 | __sint16toflt32 convert signed 16bit integer to floating point |
| 237 | __uint16toflt32 convert unsigned 16bit integer to floating point |
| 238 | __sint32toflt32 convert signed 32bit integer to floating point |
| 239 | __uint32toflt32 convert unsigned 32bit integer to floating point |
| 240 | __flt32tosint16 convert floating point value to signed 16bit integer |
| 241 | __flt32touint16 convert floating point value to unsigned 16bit integer |
| 242 | __flt32tosint32 convert floating point value to signed 32bit integer |
| 243 | __flt32touint32 convert floating point value to unsigned 32bit integer |
| 244 | @end example |
| 245 | |
| 246 | Further math library functions may be needed by user code or the C library. |
| 247 | |
| 248 | |
| 249 | |
| 250 | @section Target-Specific Variable Attributes |
| 251 | |
| 252 | This backend offers the following variable attributes: |
| 253 | |
| 254 | @table @code |
| 255 | @item __interrupt |
| 256 | Used for writing interrupt handlers. All used registers |
| 257 | (including volatiles and accumulator) are saved/restored and |
| 258 | @code{rti} is used to leave the function. Also, the user stack |
| 259 | pointer is set to @code{__isrstack}. This value for the interrupt |
| 260 | stack has to be provided e.g. by the linker script. |
| 261 | |
| 262 | @item __zpage |
| 263 | Place variable in section @code{zpage} and instruct @code{vbcc} |
| 264 | to use it with zero-page addressing. |
| 265 | |
| 266 | @item __nocpr |
| 267 | Turn off code compression for this function even if @code{-size} is used. |
| 268 | Useful for time-critical functions. |
| 269 | |
| 270 | @item __bank(<n>) |
| 271 | Place the variable/function in bank n. See chapter on banking for details. |
| 272 | |
| 273 | @end table |
| 274 | |
| 275 | @section Target-Specific #pragmas |
| 276 | |
| 277 | This backend offers the following #pragmas |
| 278 | |
| 279 | @table @code |
| 280 | @item #pragma section <sec> |
| 281 | The following functions and variables are placed in section <sec>. |
| 282 | |
| 283 | @item #pragma section default |
| 284 | The following functions and variables are placed in default sections. |
| 285 | |
| 286 | @item #pragma bank <n> |
| 287 | The following functions and variables are placed in bank <n>. See the |
| 288 | chapter on banking for details. |
| 289 | |
| 290 | @item #pragma bank -1 |
| 291 | The following functions and variables are placed in the default bank. See the |
| 292 | chapter on banking for details. |
| 293 | |
| 294 | @end table |
| 295 | |
| 296 | |
| 297 | @section Predefined Macros |
| 298 | |
| 299 | This backend defines the following macros: |
| 300 | |
| 301 | @table @code |
| 302 | @item __6502__ |
| 303 | |
| 304 | @item __SIZE_T_INT |
| 305 | |
| 306 | @end table |
| 307 | |
| 308 | |
| 309 | @section Stack |
| 310 | |
| 311 | Local variables and function arguments are put on the user stack. It |
| 312 | can be up to 64KB, but accessing variables outside the lower 256 bytes |
| 313 | is significantly slower. @code{vbcc} will put small variables on lower |
| 314 | offsets to increase the number of variables that can be addressed fast. |
| 315 | However, accessing the stack is always rather slow on the 6502. |
| 316 | |
| 317 | The stack pointer is adjusted once during function entry/exit to avoid |
| 318 | multiple costly adjustments to the stack pointer. |
| 319 | |
| 320 | Variable-length-arrays as specified in c99 should be fully supported. |
| 321 | |
| 322 | |
| 323 | @section Banking |
| 324 | |
| 325 | Many 6502 systems offer/need different banking mechanisms. vbcc offers different |
| 326 | levels of support for those schemes. Depending on the target integration, more |
| 327 | or less support is offered. |
| 328 | |
| 329 | @subsection Manual Banking |
| 330 | |
| 331 | Banking can usually be implemented manually if there is no suitable target |
| 332 | integration or if manual optimization is preferred. |
| 333 | |
| 334 | For manual banking, functions and/or data can be mapped to sections using |
| 335 | the @code{section} attribute or the @code{#pragma section} directive. Note that |
| 336 | string constants will be mapped to banked memory only when using the @code{#pragma} |
| 337 | approach. |
| 338 | |
| 339 | After placing the objects in suitable sections, they have to be located using a |
| 340 | linker command file. See the documentation on vlink. Switching between banks has |
| 341 | to done manually in a system-specific way. |
| 342 | |
| 343 | If initialized variables are mapped into banked sections, be aware that you may have |
| 344 | to provide means to initialize them on startup. It is probably not handled by |
| 345 | startup code for non-banked systems. This is not relevant for systems that only |
| 346 | provide banked ROM. |
| 347 | |
| 348 | |
| 349 | @subsection Automated Banking |
| 350 | |
| 351 | If a suitable target integration is available, vbcc is able to automatically |
| 352 | handle bank switching. |
| 353 | |
| 354 | @subsubsection Memory Model |
| 355 | |
| 356 | vbcc assumes a memory model which provides non-banked |
| 357 | memory for code and data that is always visible. Additionally there can be a |
| 358 | number of up to 255 memory banks, one of which can be visible at a time. |
| 359 | |
| 360 | If several banks can be visible at the same time, this will also work, but vbcc |
| 361 | does not make use of this feature. |
| 362 | |
| 363 | @subsubsection Mapping |
| 364 | |
| 365 | Code/data can be put into banks using the @code{bank}-attribute or |
| 366 | @code{#pragma bank}. Note that string constants will be mapped to banked memory only |
| 367 | when using the @code{#pragma} approach. Code/data not mapped to a bank will be |
| 368 | mapped to the always visible non-banked area. |
| 369 | |
| 370 | Banked objects will be mapped to sections suffixed with the bank number, e.g. in |
| 371 | |
| 372 | @example |
| 373 | __bank(0) int i = 1; |
| 374 | __bank(1) void f() { } |
| 375 | @end example |
| 376 | |
| 377 | @code{i} will be put into section @code{data0} and @code{f} will be put |
| 378 | into section @code{text1}. |
| 379 | |
| 380 | @subsubsection Bank Switching |
| 381 | |
| 382 | vbcc will try to determine when a bank switch has to |
| 383 | be made and it will call library functions to map in the required data. This |
| 384 | requires that when accessing an object, vbcc has to know which bank the object is |
| 385 | assigned to. Therefore a declaration specifying the correct bank number (either |
| 386 | using the @code{__bank()}-attribute or @code{#pragma bank}). If an object is |
| 387 | accessed which has not been declared with a bank number, it is assumed that it |
| 388 | can be accessed without bank switching. |
| 389 | |
| 390 | @subsubsection Far Pointers |
| 391 | |
| 392 | When accessing an object through a normal pointer, the bank number is not known. |
| 393 | All accesses through normal pointers assume that the target is always visible. |
| 394 | For all other cases, far-ointers have to be used. Far-pointers contain the bank number |
| 395 | as additional information, resulting in a size of 3 bytes. |
| 396 | |
| 397 | They are declared using the @code{__far}-qualifier. @code{__far} is used like a type |
| 398 | qualifier, similar to @code{const}. |
| 399 | |
| 400 | @example |
| 401 | __bank(0) i0; |
| 402 | __bank(1) i1; |
| 403 | __far int *fp; |
| 404 | ... |
| 405 | |
| 406 | if(..) |
| 407 | fp = &i0; |
| 408 | else |
| 409 | fp = &i1; |
| 410 | @end example |
| 411 | |
| 412 | Converting a far-pointer to a normal pointer will loose the bank information. |
| 413 | Converting a normal pointer to a far-pointer will insert the bank number of the current |
| 414 | function. Care must be taken not to loose bank information when working with |
| 415 | pointers. |
| 416 | |
| 417 | @subsubsection Performance Considerations |
| 418 | |
| 419 | Accessing objects through bank switching generates much slower and larger code than |
| 420 | direct accesses. Therefore it is crucial to organize your objects in a way that |
| 421 | reduces task switches as much as possible. Following is a list of hints and |
| 422 | explanations. |
| 423 | |
| 424 | @itemize |
| 425 | @item Using far pointers will always incur overhead. Try to use them only when |
| 426 | necessary. |
| 427 | |
| 428 | @item Accessing objects from the non-banked area is always fast (unless done through |
| 429 | far-pointers). |
| 430 | |
| 431 | @item Accessing objects from the same bank the function is mapped to is usually fast |
| 432 | (unless done through far-pointers). |
| 433 | |
| 434 | @item Accessing banked objects from non-banked code is usually faster than accessing |
| 435 | them from banked code in another bank. |
| 436 | |
| 437 | @item Calling functions in another bank is a reasonably small overhead on systems with a |
| 438 | fast bank switch. It can be much more overhead on RAM expansions that have to |
| 439 | copy code. |
| 440 | |
| 441 | @item Be careful when using function inlining. Inlined code will be executed in |
| 442 | the bank of the caller. |
| 443 | @end itemize |
| 444 | |
| 445 | In general, try to reduce cross-bank accesses and far-pointer usage as much as possible. |
| 446 | For best performance you can always only use the @code{section}-features to map everything |
| 447 | and handle all bank-switching yourself. |
| 448 | |
| 449 | @subsubsection Library |
| 450 | |
| 451 | To use the automated bank switching, a series of library functions must be available |
| 452 | (TODO: add more detailed information, may change): |
| 453 | |
| 454 | |
| 455 | @table @code |
| 456 | @item ___bankswitch |
| 457 | Make the bank in @code{y} accessible. |
| 458 | |
| 459 | @item ___bankjsr |
| 460 | Call the function pointer @code{r30/r31} in bank @code{y}. Return to the caller |
| 461 | in bank @code{a}. |
| 462 | |
| 463 | @item ___bankload<n> (n=1,2,3,4,8) |
| 464 | Copy <n> bytes from @code{r30/r31} in bank @code{y} to non-banked variable |
| 465 | @code{___bankv} with offset @code{x}. Caller bank in @code{a}. |
| 466 | |
| 467 | @item ___bankstore<n> (n=1,2,3,4,8) |
| 468 | Copy <n> bytes from non-banked variable @code{___bankv} with offset @code{x} to |
| 469 | @code{r30/r31} in bank @code{y}. Caller bank in @code{a}. |
| 470 | |
| 471 | @item ___bankcopy |
| 472 | Copy @code{___bankcopy_len/___bankcopy_len+1} bytes from @code{r28/r29} in bank @code{y} to |
| 473 | @code{r30/r31} in bank @code{x}. Caller bank in @code{a}. |
| 474 | @end table |
| 475 | |
| 476 | |
| 477 | @section Debugging |
| 478 | |
| 479 | The 6502 backend has some limited support for debugging. |
| 480 | |
| 481 | When using vlink, the @code{-vicelabels} options can be used to output symbol |
| 482 | values in a format that can be read by the vice emulator/debugger. |
| 483 | |
| 484 | With the @code{-g} option, line numbers and file names of source code will |
| 485 | be added to the assembly output. Using some tools, it should be possible to |
| 486 | create a mixed C/assembly file for inspection. |
| 487 | Depending on the optimization level, the |
| 488 | results may be more or less usable, see section Debugging Optimized Code. |
| 489 | Note that the added comments will affect the assembly peephole |
| 490 | optimizer, resulting in worse code than without @code{-g}. |
| 491 | |
| 492 | |
| 493 | @section Code compressor |
| 494 | |
| 495 | The @code{vcpr6502} code compressor supports the 6502 target. It should |
| 496 | be called automatically on higher optimization levels when using the |
| 497 | frontend @code{vc}. As the code will be slowed down when using compression, |
| 498 | the 6502 backend will only enable compression when using the @code{-size} |
| 499 | option. |
| 500 | |
| 501 | TODO: manual overriding |
| 502 | |
| 503 | |
| 504 | @section Known problems |
| 505 | |
| 506 | @itemize @minus |
| 507 | @item @code{long long} not yet supported |
| 508 | |
| 509 | @item return value of cross-bank function calls may not work |
| 510 | |
| 511 | @item banking not tested very much |
| 512 | |
| 513 | |
| 514 | @end itemize |
| 515 | |
| 516 | |
| 517 | |