summaryrefslogtreecommitdiff
path: root/gcc/config/stormy16/stormy-abi
diff options
context:
space:
mode:
authorupstream source tree <ports@midipix.org>2015-03-15 20:14:05 -0400
committerupstream source tree <ports@midipix.org>2015-03-15 20:14:05 -0400
commit554fd8c5195424bdbcabf5de30fdc183aba391bd (patch)
tree976dc5ab7fddf506dadce60ae936f43f58787092 /gcc/config/stormy16/stormy-abi
downloadcbb-gcc-4.6.4-554fd8c5195424bdbcabf5de30fdc183aba391bd.tar.bz2
cbb-gcc-4.6.4-554fd8c5195424bdbcabf5de30fdc183aba391bd.tar.xz
obtained gcc-4.6.4.tar.bz2 from upstream website;upstream
verified gcc-4.6.4.tar.bz2.sig; imported gcc-4.6.4 source tree from verified upstream tarball. downloading a git-generated archive based on the 'upstream' tag should provide you with a source tree that is binary identical to the one extracted from the above tarball. if you have obtained the source via the command 'git clone', however, do note that line-endings of files in your working directory might differ from line-endings of the respective files in the upstream repository.
Diffstat (limited to 'gcc/config/stormy16/stormy-abi')
-rw-r--r--gcc/config/stormy16/stormy-abi174
1 files changed, 174 insertions, 0 deletions
diff --git a/gcc/config/stormy16/stormy-abi b/gcc/config/stormy16/stormy-abi
new file mode 100644
index 000000000..887e7d76e
--- /dev/null
+++ b/gcc/config/stormy16/stormy-abi
@@ -0,0 +1,174 @@
+xStormy16 ABI
+************
+
+!!!!! NOTE !!!!!
+This document is a draft and is subject to change.
+!!!!! NOTE !!!!!
+
+This part of the file describes the conventions required to write
+ELF object files that are link-compatible with the ones produced
+by the GNU toolchains.
+
+Bit and Byte Ordering
+=====================
+
+This implementation is little-endian. Bits are numbered starting
+from 0 being the LSB.
+
+In this document, 'word' means 16 bits.
+
+Calling Sequence
+================
+
+The registers are allocated as follows:
+
+Register Purpose
+-------------------------------------------------------------------
+r0, r1 Call-volatile. May be changed during the execution
+ of a call instruction.
+r2 through r7 Argument passing; call-clobbered.
+r8, r9 Call-volatile. May be changed during the execution
+ of a call instruction.
+r10 through r13 Call-saved.
+r14 Program status word.
+r15 Stack pointer.
+
+
+Scalar values are returned in register r2-r7 if the value fits.
+Otherwise, a pointer is passed as a 'hidden' first argument and
+the return value is placed there.
+
+Arguments are passed in registers starting in r2, then on the stack.
+Arguments of size not a multiple of a word are padded to whole words.
+If an argument would otherwise be passed partially in registers, and
+partially on the stack, the whole of it is passed on the stack. The
+last argument is pushed on the stack first.
+
+After a procedure's arguments are pushed on the stack,
+the return address is pushed on the stack, as if by the call
+instruction. The return address is on the top of the stack when
+a procedure is called.
+
+Objects whose size is a multiple of 16 bits are aligned to a 16-bit
+boundary.
+
+Pointers are 16 bits, referencing addresses between 0 and 0xFFFF.
+
+Procedure pointers are also implemented as 16-bit pointers.
+
+Variable Argument Functions
+===========================
+
+The C type 'va_list' is implemented as a structure, as follows:
+
+struct {
+ char *base;
+ unsigned count;
+}
+
+Both fields are 16 bits. An argument of size N bytes
+(N will be even) is accessed as if by the following code:
+
+char *result;
+/* count = #bytes non-variable arguments */
+/* 12 = #bytes for register arguments */
+if (count + N > 12)
+ {
+ if (count < 12)
+ count = 12;
+ result = base - (count + N - 12 + 4);
+ }
+else
+ {
+ result = base + count;
+ }
+count += N;
+/* The argument is at `*result'. */
+
+
+One implementation of this is if a variadic function first
+pushes registers 2 through 7 in sequence at entry, and
+sets 'base' to the address of the first word pushed,
+producing a stack that appears like:
+
+SP ->
+ [other data]
+ r7
+ r6
+ r5
+ r4
+ r3
+count-> r2
+ Return address (two words)
+ 7th procedure parameter word
+ 8th procedure parameter word
+ ...
+ last procedure parameter word
+
+and initializes 'count' to be the number of bytes of non-variable
+arguments to the function.
+
+ELF File Format
+===============
+
+ELF file header
+---------------
+
+xStormy16 ELF files are distinguished by the value EM_XSTORMY16 in
+the e_machine field of the ELF file header:
+
+#define EM_XSTORMY16 0xad45
+
+DWARF Register Number Mapping
+-----------------------------
+
+Registers r0 through r15 are mapped to numbers 0 through 15.
+
+Relocations
+-----------
+
+RELA relocs are used exclusively. The relocation types defined are:
+
+Name Value Field Calculation Overflow
+----------------------------------------------------------------
+R_XSTORMY16_NONE 0 none none none
+R_XSTORMY16_32 1 32 S + A none
+R_XSTORMY16_16 2 16 S + A either
+R_XSTORMY16_8 3 8 S + A unsigned
+R_XSTORMY16_PC32 4 32 S + A - P none
+R_XSTORMY16_PC16 5 16 S + A - P signed
+R_XSTORMY16_PC8 6 8 S + A - P signed
+R_XSTORMY16_REL_12 7 16:12:0 S + A - P signed
+R_XSTORMY16_24 8 32:23:1 (S + A) >> 1 unsigned
+R_XSTORMY16_FPTR16 9 16 S + A either
+R_XSTORMY16_LO16 10 16 S + A none
+R_XSTORMY16_HI16 11 32:16:16 S + A none
+R_XSTORMY16_12 12 16:12:0 S + A signed
+R_XSTORMY16_GNU_VTINHERIT 128 n/a n/a n/a
+R_XSTORMY16_GNU_VTENTRY 129 n/a n/a n/a
+
+In the 'Field' column, the first number indicates whether the
+relocation refers to a byte, word or doubleword. The second number,
+if any, indicates the size of the bit-field into which the relocation
+is to occur (and also the size for overflow checking). The third
+number indicates the first bit of the bit-field in the word or
+doubleword, counting the LSB as bit 0.
+
+In the 'Calculation' column, 'S' is the value of the symbol to which
+the reloc refers, 'A' is the addend, and 'P' represents the place of
+the storage unit being relocated.
+
+In the 'Overflow' column, 'none' means that any overflow of the
+computation performed in the 'Calculation' column is ignored.
+'signed' means that the overflow is only reported if it happens when
+the values are treated as signed quantities. 'unsigned' is the same,
+except that the values are treated as unsigned quantities. 'either'
+means that overflow is reported for either signed or unsigned
+overflow.
+
+
+Copyright (C) 2001, 2002, 2003, 2005 Free Software Foundation, Inc.
+
+Copying and distribution of this file, with or without modification,
+are permitted in any medium without royalty provided the copyright
+notice and this notice are preserved.