-*- Text -*- This document describes the proposed ABI for the D30V processor. This is revision 2 of the document. Revision history: Revision 1: Original revision of this document. Revision 2: Done after consultation with Mitsubshi about the calling sequence. This revision now reduces the number of registers the compiler will not touch from 18 registers down to 8. Register 1 is now a normal temporary register, since mvfacc rx,ay,32 is legal. Arguments greater than 4 bytes must be passed in an even register or at a double word alignment. The va_list type is a structure, not a char *. The stack must be aligned to 8 byte boundary. Doubles and long longs must also be aligned to 8 byte boundaries. System calls are specified via trap 31. Revision 3: I added discussion about compiler switches. Register usage: =============== Registers Call Status Usage --------- ----------- ----- R0 hardware Hardwired to 0 R1 volatile temp R2 volatile Arg 1 and main return value. R3 volatile Arg 2 and low bits of 64 bit returns R4 - R17 volatile Args 3-16 R18 volatile Static chain if used R19 - R25 volatile temps R26 - R33 saved Reserved for user use R34 - R60 saved Registers preserved across calls R61 saved Frame pointer if needed. R62 saved Return address pointer (hardware) R63 saved Stack pointer CR0 - CR3 hardware {normal,backup} {psw,pc} CR4 - CR6 hardware Reserved for future use CR7 - CR9 volatile Repeat count, addresses CR10 - CR11 saved Modulo start/end CR12 - CR14 hardware Reserved for future use CR15 - CR17 hardware Interrupt support F0 - F1 volatile Execution flags F2 - F3 volatile General flags F4 - F7 volatile Special purpose flags A0 volatile Accumulator A1 saved Accumulator Notes on the register usage: ============================ 1) R61 will hold the frame pointer if it is needed. Normally the frame pointer will not be needed, in which case this will become another saved register. 2) Repeat instructions and delayed branches cannot cross call boundaries. Similarly, all flags are assumed to not be preserved across calls. 3) Since so many registers are available, I reserved 8 registers (r26-r33) for the user to use for any purpose (global variables, interrupt routines, thread pointer, etc.). These registers will not be used by the compiler for any purpose. 4) One of the two accumulators is saved across calls. 5) Doubles and long longs will only be allocated to even/odd register pairs to allow use of the ld2w/st2w instructions. Miscellaneous call information: =============================== 1) Structures are passed in registers, rounding them up to word boundaries. 2) Any argument that is greater than word size (4 bytes) must be aligned to a double word boundary and/or start in an even register. The intention here is to be able to use the ld2w/st2w instructions for moving doubles and long longs. 3) Variable argument functions are called with the same calling sequence as non-variable argument functions. When called, a variable argument function first saves the 16 registers (R2 - R17) used for passing arguments. The va_list type is a structure. The first element of the structure is a pointer to the first word saved on the stack, and the second element is a number that gives which argument number is being processed. 4) Word and double word sized structures/unions are returned in registers, other functions returning structures expect a temporary area address to be passed as the first argument. The stack frame when a function is called looks like: high | .... | +-------------------------------+ | Argument word #20 | +-------------------------------+ | Argument word #19 | +-------------------------------+ | Argument word #18 | +-------------------------------+ | Argument word #17 | low SP----> +-------------------------------+ After the prologue is executed, the stack frame will look like: high | .... | +-------------------------------+ | Argument word #20 | +-------------------------------+ | Argument word #19 | +-------------------------------+ | Argument word #18 | +-------------------------------+ | Argument word #17 | Prev sp +-------------------------------+ | | | Save for arguments 1..16 if | | the func. uses stdarg/varargs | | | +-------------------------------+ | | | Save area for preserved regs | | | +-------------------------------+ | | | Local variables | | | +-------------------------------+ | | | alloca space if used | | | +-------------------------------+ | | | Space for outgoing arguments | | | low SP----> +-------------------------------+ System Calls ============ System calls will be done using "TRAP 31". Input arguments will be in R2 - R5, and the system call number will be in R6. Return values from the system call will be in R2. Negative values of the return indicate the system call failed, and the value is the negative of the error code. Here are the assigned system call numbers (value in R6): exit 1 open 2 close 3 read 4 write 5 lseek 6 unlink 7 getpid 8 kill 9 fstat 10 (11 is reserved for sbrk) argvlen 12 argv 13 chdir 14 stat 15 chmod 16 utime 17 time 18 Compiler Switches ================= The following d30v specific compiler switches are currently supported: -mextmem Link .text/.data/.bss/etc in external memory. -mextmemory Same as -mextmem. -monchip Link .text/.data/.bss/etc in the onchip data/text memory. -mno-asm-optimize Do not pass -O to the assembler when optimizing (the -O switch will mark two short instructions that don't interfere with each other as being done parallel instead of sequentially). -masm-optimize [default] If optimizing, pass -O to the assembler. -mbranch-cost=n Increase the internal costs of branches to n. Higher costs means that the compiler will issue more instructions to avoid doing a branch. The default is 2. -mcond-exec=n Replace branches around n insns with conditional execution if we can. Default is 4. Sections ======== You can override the effect of the -mextmem/-monchip options by putting functions into either the ".stext" or ".etext" sections. If you put them into the ".stext" section, the linker will always link the function into the onchip memory area. Similarly, if you put the function in the ".etext" section, the linker will always link the function into the external memory area. Data can be controlled as well. If you put the data in the ".sdata" section, the linker will put the data into the onchip data area. Similarly, if you put the data in the ".edata" section, the linker will put the data into the external memory. Stack pointer ============= The crt0.o that we ship loads up the stack pointer with the value of the label __stack. If you do not define a value for __stack, the linker will choose the top of the onchip data area (0x20008000) for the stack pointer. You can set a new value via the options: -Wl,-defsym,__stack=0x20008000