ABI 4.0 Spec

Specification
February 2007
StarCore ABI 4.0
Agere Systems - Proprietary
Introduction
This document is a reference for the StarCore
Application Binary Interface (ABI) for the following
families of StarCore processor cores (and earlier
cores):
SC1000
SC2000
SC3000
The ABI definition ensures interoperability between
different tools, like compiler, assembler, linker and
debugger on object code level.
This document is intended for tool developers as
well as for low level assembly programmers.
To summarize , this document will discuss the
following topics:
The low level binary interface. It contains a
definition of all basic data types and the function
calling conventions.
The high level language issues. It describes the
C++ABI and the runtime functions of the
library.
The object file format. It describes the StarCore
extensions to the ELF object file format.
Specification
February 2007 Contents
Agere Systems - Proprietary 3
Contents
Preface About This Document 13
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Whats covered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Conformance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Source Level Compatibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Whats New in StarCore ABI 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Numbering systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Typographic notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Special terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Chapter 1 Low-Level Binary Interface 19
StarCore Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Endian Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Fundamental Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Aggregates and Unions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Bit Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Argument Passing and Register Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Argument Passing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Return Value Passing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Register saving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Register Saving and Restoring Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
ABI indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Argument Passing and Register Usage of ABI Version 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Argument Passing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Variable Argument Passing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Return Value Passing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Register Saving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Register Saving and Restoring Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Stack Pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Frame and global pointers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Stack frame layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Stack unwinding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Configuration Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Field Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Status Register (SR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Exception and Mode Register (EMR). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
General Configuration Register (GCR). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Specification
Contents February 2007
4 Agere Systems - Proprietary
Modifier Control (MCTL) Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Hardware loops. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Static Programming Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Enforce at COF Source. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Enforce at COF Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Loop Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Memory Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Code Memory Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Data Memory Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Chapter 2 High-Level Language Issues 47
Name Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
C Name Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
C++ Name Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
C System Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Compiler assist libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
setjmp and longjmp layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Dynamic memory allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Calling conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Floating-point routines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Integer and fractional arithmetic routines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Optional long long routines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Register saving and restoring functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
C++ Support Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
C++ ABI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Controlling Object Construction Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
DSO Object Destruction API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Demangler API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Exception Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
External Names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Vague Linkage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Chapter 3 Object File Format 63
Interface Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
The ELF Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Sections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Special Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
.SC100.delay_slots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
.mw_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
.rom_init_tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
.bsstab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
.ovltab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Relocation types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Specification
February 2007 Contents
Relocation stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Instruction address vs. VLES address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
NOTE Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Program Headers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Debugging Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
DWARF register number mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Specification
Contents February 2007
Specification
February 2007 Tables
Tables
1 Mapping of C data types to the StarCore architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2 Mapping of C fractional types to the StarCore architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3 C bit field types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4 Register usage in the ABI 4 calling convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5 Register usage in the ABI 2 calling convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6 StarCore ELF sections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7 Relocation type definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8 Relocation stack operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
9 StarCore register number mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Specification
Tables February 2007
Specification
February 2007 Figures
Figures
1 Stack frame layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2 Object file format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3 Vendor identification note format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4 User (application-specific) note format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Specification
Figures February 2007
Specification
February 2007 Examples
Examples
1 Word bit and byte numbering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2 Long word bit and byte numbering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3 Double-long word bit and byte numbering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Structure with internal and tail padding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5 Union allocation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6 Bit field alignment and padding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7 Unnamed and zero-width bit fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8 Function calls and allocation of arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9 Function calls and allocation of arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10 Generating stack unwinding symbols in assembly code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
11 Code memory models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
12 Data memory models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
13 Saving and restoring functions usage example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
14 ELF header structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
15 StarCore specifics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
16 Definition of macros for accessing e_flag parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
17 Section header structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
18 Definition of opcode IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
19 Definition of macros for accessing opcode parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
20 Relocation entry defined with Elf32_Rela . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
21 Program header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Specification
Examples February 2007
Preface About This Document
Overview
Purpose This document defines a set of standards intended to ensure interoperability between
conforming software components, such as, compilers, assemblers, linkers, debuggers on
object code level. These standards cover run-time aspects as well as object formats to be
used by compatible tool chains from StarCore and third party tools developers.
A benefit of this standard definition is interoperability of conforming tools. This allows
users to select the best tool for each phase of the application development cycle, rather
than being constrained to using an entire tool chain. Another benefit is compatibility of
conforming libraries. Programmers can build compatible binary libraries and assembly
code libraries, and be assured of their continued compatibility over time.
On the other hand, the ABI is designed to include only the minimal set of rules to ensure
object code compatibility. This gives a tool implementation the maximum flexibility.
Whats covered This specification addresses the following types of standards:
Low level run-time binary interface standards
Processor-specific binary interface (the instruction set and representation of
fundamental data types)
Function calling conventions (how arguments are passed and results are returned,
how registers are assigned, and how the calling stack is organized)
Object-file binary interface standards
Header convention
Section layout
Relocation information format
Debugging information format
Library standards
Compiler run-time libraries (integer routines and floating-point routines)
Conformance The ABI defines how separatly compiled and assembled modules can be used together in a
single application. This means that object files from different tool chains may be
combined in a single executable file.
Preface Specification
About This Document February 2007
Overview
The ABI conformance is defined on public visible interfaces (e.g. external visible
functions or variables) of an object file. But a compiler implementation is free to make
deviations to the ABI for internal interfaces.
This means for example if two functions are in the same compilation module,
the compiler may take the set of used resources of the called function into
account. So the caller function may use free hardware loop resources or avoid
saving of untouched scratch registers. For static functions, the compiler may
even change the whole calling convention within a module.
A compiler implementation may implement optional deviations to the ABI, which have to
be explicitly enabled (e.g. by command line options). It must be defined by the compiler
implementation how such deviations are compatible to the standard ABI.
For example a compiler may provide a command line option to specify a
different default setting for mode bits. In this case all object files must be
compiled with this command line option to be compatible.
Features defined in this ABI are mandatory unless specifically stated otherwise. Optional
features, if implemented, must conform to the ABI.
Source Level
Compatibility
Source level compatibility on C or assembly source level is not defined in the ABI. But it
is recommended that compiler and assembler implementations follow the source level
conventions as described in the StarCore compiler and assembler manuals. These include
Assembly syntax
Compiler intrinsics
Pragmas
C/C++language extentions
Inline assembly
Specification Preface
February 2007 About This Document
Whats New in StarCore ABI 4.0
Whats New in StarCore ABI 4.0
StarCore ABI 4.0 supersedes the previous revision (3.0) and includes information that
applies to the following StarCore families:
SC1000
SC2000
SC3000
Major changes from the previous revision include:
Chapter 3, Object File Format:
Added four new relocation types for the SC3000-family cores.
Additional Resources
Additional Resources
The following standards provide useful reference information:
Tool Interface Standard (TIS) Executable and Linking Format (ELF) Specification,
Version 1.1, UNIX Systems Laboratories, Portable Formats Specification, 1995
DWARF Debugging Information Format, Revision: Version 2.0.0, Industry Review
Draft, UNIX International, Program Languages SIG, J uly 27, 1993
ANSI/IEEE Std 754-1985, IEEE standard for binary floating-point arithmetic data
types
ISO/IEC 9899:1999(E), International Standard - Programming LanguagesC, 2nd
Edition, International Organization for Standardization, December 1, 1999
ISO/IEC 14882:2003(E), International Standard - Programming LanguagesC, 2nd
Edition, International Organization for Standardization, October 15, 2003
Itanium C++ ABI, revision 1.71 (http://www.codesourcery.com/cxx-abi/abi.html)
also referred to as The Generic C++ABI.
The following StarCore documents are included by reference into this ABI.
SC1000-Family Processor Core Reference Manual
Describes the SC1000-family core architecture and programming model, including the
SC1200 and SC1400 instruction set.
StarCore C/C++ Compiler User Manual
Describes the StarCore compiler.
StarCore Assembler User Manual
Describes the StarCore assembler.
StarCore Linker User Manual
Describes the StarCore linker.
Specification Preface
February 2007 About This Document
Conventions
Conventions
Introduction This document uses certain conventions to assist you in identifying, locating, and
understanding information.
Numbering systems The following suffixes identify different numbering systems:
Typographic notation The following typographic notations are used throughout this document:
Special terms The following terms have special meanings:
This suffix Identifies a
b Binary number. For example, the binary equivalent of the number 5 is written 101b.
d Decimal number. Decimal numbers are followed by this suffix only when the possibility of
confusion exists. In general, decimal numbers are shown without a suffix.
h Hexadecimal number. For example, the hexadecimal equivalent of the number 60 is written 3Ch.
Example Description
placeholder Items in italics are placeholders for information that you provide. Italicized text is also used
for the titles of publications and for emphasis.
code Fixed-width type indicates text that must be typed exactly as shown. It is used for
instruction mnemonics, symbols, subcommands, parameters, and operators. Fixed-width
type is also used for example code.
Term Meaning
byte An 8-bit data object
double-long A 64-bit data object
long A 32-bit data object
word A 16-bit data object
Acknowledgements
Acknowledgements
The StarCore Application Binary Interface team included representatives from the
following companies:
We gratefully thank all participants for devoting their time and effort to create this
standard.
Agere Systems Inc. Metrowerks, Inc.
Altium Limited Motorola, Inc.
Green Hills Software, Inc. WindRiver Systems, Inc.
Lineo, Inc.
Chapter 1 Low-Level Binary Interface
This chapter defines low-level system standards for the StarCore architectures of
processor cores, including:
Processor-specific binary interface (the instruction set and representation of
fundamental data types)
Function calling conventions (how arguments are passed and results are returned, how
registers are assigned, and how the calling stack is organized)
StarCore Architectures
The StarCore processor core architectures currently includes six cores: the SC1200, the
SC1400P, the SC2200, the SC2400 , the SC3200, and the SC3400. The architecture and
instruction set for each core is defined in that cores respective reference manual, as listed
in Additional Resources on page16. Programs written for these cores use their
instruction sets, as well as the instruction encodings and semantics of their architecture.
Programmers may assume that the instructions for these cores work as documented. Note
that all cores are backwards compatible to their respective predecessor, but while an
ABI-conforming SC1200 program will run on an ABI-conforming SC1400 processor, the
reverse is not always true.
To conform to the ABI, the processor must execute the architectures instructions and
produce the expected results. This ABI does not define requirements for the services
provided by an operating system, nor does it specify what instructions must be
implemented in hardware. A software emulation of the architecture could conform to the
ABI.
Programs that use non-StarCore instructions or capabilities do not conform to the StarCore
ABI. Such programs may produce unexpected results when run on machines lacking the
non-StarCore capability.
Chapter 1 Specification
Low-Level Binary Interface February 2007
Endian Support
Endian Support
The StarCore architecture supports both big-endian and little-endian implementations.
This standard defines a binary interface for each. Note that program binaries that run on a
big-endian implementation are not portable to a little-endian implementation, and vice
versa. The same applies to the data generated by these programs, as well as to the layout of
data used by these programs (such as the layout of data generated by compilation tools).
The bytes that form the supported data types are ordered in memory according to the
following:
In a big-endian implementation, the most significant byte (MSB) is located in the
lowest address (byte 0).
In a little-endian implementation, the least significant byte (LSB) is located in the
lowest address (byte 0).
Specification Chapter 1
February 2007 Low-Level Binary Interface
Fundamental Data Types
The StarCore architecture defines the following data types:
An 8-bit byte
A 16-bit word
A 32-bit long word
A 64-bit double-long word
The mapping of these data types depends on whether this data is mapped to registers or
memory. Data stored in registers are always little-endian mapped, whereas data in
memory are mapped according to the current endian mode.
Example1. Word bit and byte numbering
Register mapping
Memory mapping
Example2. Long word bit and byte numbering
Register mapping
Memory mapping
bit 15 8 7 0
byte 1
MSB LSB
byte 0
Little-Endian
bit 15 8 7 0
byte 1
MSB LSB
byte 0
Big-Endian
bit 15 8 7 0
byte 1
MSB LSB
byte 0
Little-Endian
bit 15 8 7 0
byte 0
MSB LSB
byte 1
Big-Endian
bit 31 24 23 16 15 8 7 0
byte 3
MSB LSB
byte 0
Little-Endian
bit 31 24 23 16 15 8 7 0
byte 3
MSB LSB
byte 0
Big-Endian
bit 31 24 23 16 15 8 7 0
byte 3
MSB LSB
byte 0
Little-Endian
bit 31 24 23 16 15 8 7 0
byte 0
MSB LSB
byte 3
Big-Endian
Example3. Double-long word bit and byte numbering
Register mapping
Memory mapping
Note Support for 64-bit data is optional and an implementation may not accept the long
long C type.
bit 31 24 23 16 15 8 7 0
Little-Endian
byte 3
LSB
byte 0
bit 63 56 55 48 47 40 39 32
byte 7
MSB
byte 4
bit 31 24 23 16 15 8 7 0
Little-Endian
byte 3
LSB
byte 0
bit 63 56 55 48 47 40 39 32
byte 7
MSB
byte 4
bit 31 24 23 16 15 8 7 0
Little-Endian
byte 3
LSB
byte 0
bit 63 56 55 48 47 40 39 32
byte 7
MSB
byte 4
bit 63 56 55 48 47 40 39 32
Big-Endian
byte 0
MSB
byte 3
bit 31 24 23 16 15 8 7 0
byte 4
LSB
byte 7
Table1 shows the mapping between these fundamental data types and the C language data
types. Note that fundamental data is always naturally aligned; that is, a double-long word
is 8-byte aligned, a long word is 4-byte aligned, and a word is 2-byte aligned.
Table 1. Mapping of C data types to the StarCore architecture
Type C type Size
(bits)
Alignment
(bits)
Limits StarCore
_Bool
1
8 8 0 through 1 Signed byte
Character char 8 8 2
7
through 2
7
1 Signed byte
si gned char
unsi gned char 8 8 0 through 2
8
1 Unsigned byte
shor t 16 16 2
15
through 2
15
1 Signed word
si gned shor t
unsi gned shor t 16 16 0 through 2
16
1 Unsigned word
Integral i nt 32 32 2
31
through 2
31
1 Signed long word
si gned i nt
enum
l ong
si gned l ong
unsi gned i nt 32 32 0 through 2
32
1 Unsigned long word
unsi gned l ong
l ong l ong
1
64 64 2
63
through 2
63
1 Signed double-long
word
si gned l ong l ong
1
unsi gned l ong l ong
1
64 64 0 through 2
64
1 Unsigned double-
long word
Pointer poi nt er t o dat a 32 32 0 through 2
32
1 Unsigned long word
poi nt er t o f unct i on
Floating-
point
2
f l oat 32 32 3.402e
38
through 1.175e
38
1.175e
38
through 3.402e
38
Unsigned long word
doubl e
3
32 or
64
32 or 64 2.225e
308
through 1.797e
308

or 1.175e
38
through 3.402e
38
Unsigned double-
long word
l ong doubl e
3
1
This data type is specified in the latest ISO C definition (ISO/IEC 9899:1999). Support of this data type is optional. If
used, this data type must be implemented with the size and alignment shown.
2
Floating-point types conform to the IEEE 754 format.
3
An implementation may choose between a 32-bit and a 64-bit doubl e type. A 32-bit doubl e is essentially the same
as a f l oat .
Fractional types are supported in C using intrinsic functions; Table2 shows the fractional
types that are supported.

Table 2. Mapping of C fractional types to the StarCore architecture
C type C type definition Size
(bits)
Alignment
(bits)
Limits
Fractional shor t 16 16
1 through
Long fractional l ong
i nt
32 32
1 through
Long fractional with extension
bits
Little-endian:
t ypedef st r uct {
unsi gned l ong body;
char ext ;
} Wor d40;
Big-endian:
t ypedef st r uct {
unsi gned l ong body;
char gap[ 3] ;
char ext ;
} Wor d40;
64 32
256 through
Double precision fractional t ypedef st r uct {
l ong msb;
unsi gned l ong l sb;
} Wor d64;
64 64
*
1 through
*
A word64 is 8-bytes aligned.
2
15
1 ( )
2
15
----------------------
2
31
1 ( )
2
31
----------------------
2
39
1 ( )
2
31
----------------------
2
63
1 ( )
2
63
----------------------
Aggregates and Unions
The alignment of aggregates (structures and unions) is the maximum of the following
values:
The alignment of their most strictly aligned member (that is, the member with the
largest alignment).
A minimum alignment of 4.
An implementation may provide a user option that overrides the minimum structure
alignment. In particular, if the user may select a minimum alignment of 0 or 1, the
aggregate alignment is simply the largest alignment of its members.
Modules compiled with different minimum alignments cannot interoperate if they
interface using structures or unions.
For example, a structure containing a char , a shor t , and an i nt must have a 4-byte
alignment to match the alignment of the i nt . Arrays have the same alignment as their
individual elements.
The size of any structure, array, or union must be an integral multiple of its alignment.
Structure and unions may require padding to meet size and alignment constraints:
An entire structure or union is aligned on the same boundary as its most strictly aligned
member.
Each member is allocated starting at the next byte that satisfies the alignment
requirement for that member. This may require internal padding.
If necessary, a structures size is increased to make it a multiple of the structures
alignment. This may require tail padding, depending on the last member.
In both endian modes, members are allocated starting with the low order (lowest
addressed) byte of the structure or union, as shown in the following examples. In
Example4, there is internal padding so that the first shor t (s1) starts at a word boundary.
Tail padding makes the structure size a multiple of the i nt members 4-byte alignment.
Example4. Structure with internal and tail padding
st r uct { / * 12 byt es, 4- byt e al i gned */
char c;
shor t s1;
i nt i ;
shor t s2;
};
Example5. Union allocation
uni on { / * 4 byt es, 4- byt e al i gned */
shor t s;
char c;
l ong l ;
};
bit 31 16 15 8 7 0
Little-Endian
byte 3
s1 pad c
byte 0
bit 63 32
byte 7
i
byte 4
bit 95 80 79 64
byte 11
pad s2
byte 8
bit 95 88 87 80 79 64
Big-Endian
byte 0
c pad s1
byte 3
bit 63 32
byte 4
i
byte 7
bit 31 16 15 0
byte 8
s2 pad
byte 11
bit 31 16 15 8 7 0
Little-Endian
byte 3
pad s
byte 0
pad c
l
bit 31 24 23 16 15 0
Big-Endian
byte 0
s pad
byte 3
c pad
l
Bit Fields
Bit Fields
Structure and union definitions may have bit fields as listed in Table3.
Support of _Bool is optional, but all other types shown in Table3 must be supported. This
ABI does not have requirements for l ong l ong bit fields.
Unsigned bit-field values range from 0 to 2
w1
, where w is the bit fields width in bits.
Signed bit-field values range from 2
w1
to 2
w1
1.
Table 3. C bit field types
C type Maximum width (bits)
_Bool
1
char
2
si gned char
2
unsi gned char
2
1 to 8
shor t
2
si gned shor t
2
unsi gned shor t
2
1 to 16
i nt
si gned i nt
enum
2
l ong
2
si gned l ong
2
unsi gned i nt
unsi gned l ong
2
1 to 32
1
Support of _Bool is optional. If implemented, it must be implemented with the width and range shown.
2
This bit field type is not required for ISO C conformance, but is required for ABI conformance.
Bit Fields
A plain bit field (one that is not explicitly declared signed or unsigned) is signed.
Although they may have type char , shor t , i nt , or l ong (which can have negative
values), bit fields of these types have the same range as bit fields of the same size with the
corresponding signed type. The same size and alignment rules that apply to other structure
and union members also apply to bit fields. The following rules additionally apply to bit
fields:
In little-endian implementations, bit fields are allocated right to left. The first bit field
occupies the least significant bits while subsequent bit fields occupy more significant
bits.
In big-endian implementations, bit fields are allocated left to right. The first bit field
occupies the most significant bits while subsequent bit fields occupy less significant
bits.
A bit field may not cross a boundary for its type. For example, a signed char bit field
cannot exceed eight bits in width, and it cannot cross a byte boundary.
Bit fields must share a storage unit with other structure and union members (either bit
field or non-bit field) if and only if there is sufficient space within the storage unit.
An unnamed bit field does not affect the alignment of its enclosing structure or union,
although an individual bit fields member offsets obey the alignment constraints. An
unnamed, zero-width bit field prevents any further member (either bit field or non-bit
field) from residing in the storage unit corresponding to the type of the zero-width bit
field.
Note in the following examples that alignments are driven not by the widths of the bit
fields but by the underlying types. Example6 shows a structure that is 4-byte aligned and
has a 4-byte size because of the i nt bit fields. There is internal padding so that the char
bit field does not cross a byte boundary, and so that the shor t member starts at a word
boundary. All members share a long word.
Example6. Bit field alignment and padding
i nt a : 3;
i nt b : 4;
char c : 5;
shor t d;
};
bit 31 16 15 13 12 8 7 6 3 2 0
byte 3
d pad c b a
byte 0
Little-Endian
pad
bit 31 28 25 24 23 19 18 16 15 0
byte 0
a b c pad d
byte 3
Big-Endian
pad
Bit Fields
In Example7, the structure is at least 2-byte aligned because the unnamed l ong bit field
does not affect structure alignment. (The actual alignment depends on the type alignment -
2 in this example - and the minimum structure alignment - see Aggregates and Unions
on page25.) The zero-width shor t bit field pads to the next word boundary.
Example7. Unnamed and zero-width bit fields
shor t a : 9;
shor t : 0;
char b : 5;
l ong : 15;
};
bit 31 21 20 16 15 9 8 0
Little-Endian
byte 3
pad b pad a
byte 0
bit 63 32
byte 7
pad
byte 4
bit 63 55 54 48 47 43 42 32
Big-Endian
byte 0
a pad b pad
byte 3
bit 31 0
byte 4
pad
byte 7
Argument Passing and Register Usage
This section describes the argument passing and register usage of the ABI version 4. It
differs from the calling convention of ABI version 2. An implementation may optionally
provide both versions of the calling conventions.
Argument Passing The compiler tries to pass the first function arguments via the registers D0 to D3, and R0
to R3, according to the following rules:
If a function argument is of integral, floating point, or structure type, and its size is less
than or equal to 32bits, the argument is passed in a data register (D0 to D3). All
register bits exceeding the arguments size are defined by the sign of the corresponding
type. For example, an argument of type shor t is passed in bits 150 and bits 3916 are
equal to the value of bit 15 (the sign bit).
If a function argument is of pointer type, it is passed in an address register (R0 to R3).
If an implementation supports 64bits scalar data types (i.e. unsi gned l ong l ong,
l ong l ong or doubl e) and a function argument is of this type, it is passed in a data
register pair (either D0 and D1, or D2 and D3).The data register with the lower number
contains the most significant 32bits (sign or zero extended to 40bits, according to the
type), the other one contains the least significant 32bits (zero extended to 40bits),
regardless of the byte order.
If a function argument is of structure type, and its size is larger than 32bits and less or
equal to 64bits, it is passed in a data register pair (either D0 and D1, or D2 and
D3).The data register with the lower number contains the most significant 32bits, the
other one contains the least significant 32bits.
The register arguments are allocated while working off the argument list from left to
right. Whenever an argument fulfills one of the previously mentioned data type criteria
and a register (or register pair) out of the corresponding register list is still available, it
is assigned.
All arguments that are not passed via registers are passed on the stack. Stack arguments
adhere the rules of the previously specified standard calling convention.
Variable argument passing is handled as previously specified.
Return Value Passing The return value is handled similar like the function arguments:
If the return value is of integral, floating point, or structure type, and its size is less than
or equal to 32bits, the return value is passed in D0. All register bits exceeding the
return values type size are defined by the sign of the corresponding type. For example,
an argument of type shor t is passed in bits 150 and bits 3916 are equal to the value
of bit 15 (the sign bit).
If an implementation supports 64bits scalar data types (i.e. unsi gned l ong l ong,
l ong l ong or doubl e) and a function return value is of this type, it is passed in the
data register pair D0 and D1. D0 contains the most significant 32bits (sign or zero
extended to 40bits, according to the type), D1contains the least significant 32bits
(zero extended to 40bits), regardless of the byte order.
If the return value is of structure type, and its size is larger than 32bits and less or equal
to 64bits, it is passed in D0 and D1. D0 contains the most significant bits, D1 contains
the least significant 32bits.
If the return value is of pointer type, it is passed in R0.
A st r uct or uni on larger than 64bits causes the compiler to allocate stack space for
the data structure on the caller's stack frame. The called function obtains a pointer to
the stack location in register R0 as a hidden function parameter. Hence the list of
available address registers for argument passing shrinks to R1, R2, R3.
Register saving A function must preserve following registers:
D4, D5, D6, D7: Only bits 0-31 are preserved. The extension bits (32-39) are either
preserved or set to the value of bit 31, i.e. the register is sign extended.
R4, R5, R6, R7
All other registers may be destroyed by a function.
Register Saving and
Restoring Functions
The compiler may use runtime function calls instead of PUSH and POP instructions for
register saving and restoring to reduce code size. These functions are described in
Register saving and restoring functions on page57.
Example8. Function calls and allocation of arguments
Function Call 1:
char count ( char sc, l ong l ong l l , unsi gned shor t us) ;
When the count function is called in the source code, the compiler passes the first
argument (sc) in D0, and the second argument (l l ) in the register pair D2 and D3. Finally
the last argument (us) is passed in D1, as this is the last available data register. Bits398
of D0 are set to bit 7 (sign bit). Bits3932 of D2 are set to zero and bits3932 of D3 are
set to bit 31 (sign bit). The last argument is unsigned, hence bits3916 of D1 are set to
zero. The caller expects the return value in the least significant 8bits of D0. Bits398 of
D0 are equal to the sign bit (bit 7).
Function Call 2:
st r uct poi nt r ot at e ( Wor d40 x, i nt *i , char *f or mat , . . . ) ;
When the r ot at e function is called in the source code, the compiler passes the first
function argument (x) in the register pair D0 and D1, the second argument (a pointer to i )
in R0, and all further arguments on the stack. However, if the returned structure (st r uct
poi nt ) has a size of more than 64 bits, the compiler uses the address register R0 as
pointer to the structure and the second function argument (pointer to i ) is passed in R1.
Table4 summarizes register usage in the ABI 4 calling convention.
ABI indicators To avoid an accidentally mismatch of calling conventions, the linker checks if the calling
conventions of caller and callee functions match. The compiler generates special
indication-symbols for all ABI4 functions and function references. The indication-
symbols have following naming convention:
__abi 4. function-label-name
For example the function f oo( ) has the label name _f oo and the ABI4 indication symbol
is named __abi 4. _f oo. These symbols are generated for functions, which are defined in
a module and functions, which are referenced from a module.
With this information the linker prints an error if an ABI4 function calls an ABI2 function
or vice versa. Note that this error checking is not done if a function is called over a
function pointer.
Table 4. Register usage in the ABI 4 calling convention
Register Caller
saved
Callee
saved
Remark
D0 + First numeric argument
Return numeric value
D1-D3 + Second to fourth numeric argument
D4D7 +
D8D15 +
D0.eD3.e +
D3.eD7.e + The extension bits are either not modified by the callee or sign extended,
i.e. bits 31 to 39 are equal.
D8.eD15.e +
R0 + First pointer argument
Return pointer value
Structure or union return address
R1-R3 + Second to fourth pointer argument
R4-R7 +
R8R15, B0B7 +
N0N3, M0M3 +
SP (NSP, ESP) +
Argument Passing and Register Usage of ABI Version 2
This section describes the argument passing and register usage of the ABI version 2. This
version of the calling convention is only provided for backward compatibility. An
implementation should prefer the ABI version 4 calling convention. An implementation
may optionally provide both versions of the calling conventions.
Argument Passing Arguments are passed to functions according to the following standard calling convention.
If the first function argument is 4 or fewer bytes and is an integral type or floating type,
the argument is passed in D0. If it is a pointer, it is passed in R0. If the first argument is
a structure or union, it is passed on the stack.
If the first argument is a l ong l ong (where implemented), doubl e, or l ong
doubl e, it is passed in D0 and D1, D0 containing the most significant long word and
D1 containing the least significant long word, regardless of the endianess mode.
If the second argument is 4 or fewer bytes and is an integral type or floating type and
D1 is not already used by the first argument, the argument is passed in D1. If it is a
pointer, it is passed in R1. If the second argument is a structure or union, it is passed on
the stack.
When an argument is passed in D0 or D1, all the register bytes that are part of the
argument are defined by extension to the corresponding type. For example, a first
argument of type short is passed in D0[15:0], and the contents of D0[31:16] and D0.e
contain the sign of the argument. An argument of type float is passed in D[31:0], sign-
extended to 40 bits.
When an argument is passed in both D0 and D1, D1.e contains zero and D0.e is defined
by extension to the corresponding type: sign-extending the 32 most significant bits for
long long and long double, zero-extending the 32 most significant bits for unsigned
long long.
All other arguments are passed on the stack. Note that the first argument may be passed
on the stack, followed by the second argument being passed in D1 or R1.
Arguments are passed on the stack, in order, from higher addresses to lower addresses.
Each argument on the stack is passed in the byte order appropriate for the endian mode.
An argument that is 8-byte aligned according to Fundamental Data Types on
page21, Aggregates and Unions on page25, and Bit Fields on page27 is passed
8-byte aligned on the stack. All other arguments are passed using their alignment
constrains. For example, a short type is 2-byte aligned.
The constituent bytes of an integral argument of fewer than 4 bytes are located on the
stack using their original size and constrains.
The alignment of aggregates on the stack is at least 4 bytes, even if the compiler
optionally supports an aggregate alignment of less than 4 bytes.
Variable Argument
Passing
ANSI C requires that before a function with a variable argument list is called, it must be
declared with a prototype containing a trailing ellipsis (. . . ). Following rules apply to
functions with variable arguments.
Functions with a variable number of arguments pass the last fixed argument and all
subsequent variable arguments on the stack. Such arguments of fewer than 4 bytes are
located on the stack as if the argument had been promoted to 32 bits. The rules above
apply to arguments before the last fixed argument.
Variable arguments, which have a size of 8 bytes or more, are passed 8-bytes aligned
on the stack.
If the compiler supports aggregates with an alignment of less than 4 bytes then
following rule applies for variable arguments in big endian: The padding bytes of
aggregates with a size, which is not a multiple of 4 bytes, are inserted before the
aggregate. I.e. in big endian, the aggregate stack end address (and not the start address)
of a variable argument is always 4 or 8 bytes aligned.
Return Value Passing Return values are passed according to the following rules
An integral return value, other than a l ong l ong, is sign or zero extended to 40 bits
and returned in D0. A float value is returned in D0, sign-extended to 40 bits. A l ong
l ong, doubl e, or l ong doubl e return value is returned in D0 and D1, D0 containing
the most significant long word and D1 containing the least significant long word,
regardless of the endianess mode. D1 is zero-extended to 40 bits. D0 is sign-extended
to 40 bits for returned values of type long double and long long, and it is zero-extended
to 40 bits for unsigned long long.
A pointer return value is returned in R0.
A function returning a structure or union receives in R2 the address of the returned
structure or union. The caller allocates space for the returned object.
Register Saving A function must preserve following registers:
D6, D7: Only bits 0-31 are preserved. The extension bits (32-39) are either preserved
or set to the value of bit 31, i.e. the register is sign extended.
R6, R7
All other registers may be destroyed by a function.
Register Saving and
Restoring Functions
The compiler may use runtime function calls instead of PUSH and POP instructions for
register saving and restoring to reduce code size. These functions are described in
Register saving and restoring functions on page57.
Example9 shows two function calls and the arguments that are allocated for each call.
Example9. Function calls and allocation of arguments
Function Call 1:
f oo( i nt a1, st r uct f our byt es a2, st r uct ei ght byt es a3, shor t a4)
Arguments:
a1 - i n r egi st er d0
a2 - on t he st ack at SP - 4 ( SP = st ack poi nt er addr ess)
a3 - on t he st ack at SP - 12
a4 - on t he st ack at SP - 14
Function Call 2:
bar ( l ong *b1, i nt b2, char b3, i nt b4[ ] )
Arguments:
b1 - i n r 0
b2 - i n d1
b3 - on st ack at SP - 4
b4 on st ack at SP - 8
Table5 summarizes register usage in the ABI 2 calling convention.
Table 5. Register usage in the ABI 2 calling convention
Register Caller
saved
Callee
saved
Remark
D0 + First numeric argument
Return numeric value
D1 + Second numeric argument
D2D5 +
D6D7 +
D8D15 +
D0.eD5.e +
D6.eD7.e + The extension bits are either not modified by the callee or sign extended,
i.e. bits 31 to 39 are equal.
D8.eD15.e +
R0 + First pointer argument
Return pointer value
R1 + Second pointer argument
R2 + Structure or union return address
R3R5 +
R6-R7 +
R8R15, B0B7 +
N0N3, M0M3 +
SP (NSP, ESP) +
Stack
Stack
Stack Pointer The SP register serves as the stack pointer. SP will point to the first available location,
with the stack direction being towards higher addresses (that is, a push will be
implemented as (sp)+). Initially a long word with value 1 is pushed at offset 0 on the
stack to serve as a top-of-stack marker. The stack pointer must be 8-byte aligned.
Frame and global
pointers
This ABI standard does not require the use of a frame pointer or a global pointer. If,
however, the use of a frame pointer or a global pointer is necessary, a compiler may
allocate R7 as a frame pointer and R6 as a global pointer. When these registers are
allocated for this purpose, they should be saved and restored as part of the function
prologue/epilog code.
Stack frame layout The stack pointer points to the top (high address) of the stack frame. Space at higher
addresses than the stack pointer is considered invalid and may actually be unaddressable.
The stack pointer value must always be a multiple of eight.
Figure1 shows typical stack frames for a function and indicates the relative position of
local variables, arguments, and return addresses. The stack grows upward from low
addresses.
The outgoing arguments area is located at the top (higher addresses) of the frame.
The caller puts argument variables that do not fit in registers into the outgoing arguments
area. If all arguments fit in registers, this area is not required. A caller may allocate
outgoing arguments space sufficient for the worst-case call, use portions of it as necessary,
and not change the stack pointer between calls.
Local variables that do not fit into the local registers are allocated space in the local
variables area of the stack. If there are no such variables, this area is not required.
The caller must reserve stack space for return variables that do not fit in registers. This
return buffer area is typically located with the local variables, but it may be the address of
a global variable. This space is typically allocated only in functions that make calls
returning structures.
A return address value of FFFFFFFFh (1) is used to denote the current frame as the
outermost (oldest) frame on the current call stack. This convention requires that the
outermost frame be manually constructed and that sufficient object file details are
available to determine the sizes of all frames on the current call stack. The sole purpose of
this convention is to stop stack unwinding while debugging.
Beyond these requirements, a function is free to manage its stack frame in any way
desired.
Stack
Figure 1. Stack frame layout
Stack unwinding The compiler will create special symbols when a module is compiled without debug
enabled (for example., the - g compiler option is not used). These symbols will appear as
local symbols in the . symt ab ELF section and will have the following syntax:
Text St ar t _<modul e_name> : modul e s l ow PC
Text End_<modul e_name> : modul e s hi gh PC
St ackOf f set _<l abel > : si ze of st ack at l abel
FuncEnd_<f unct i on_name> : f unct i on s hi gh PC
Where:
<module_name>is the base name of the source file. The base name must follow the
same conventions as assembly language labels. These conventions are outlined in
Symbol names on page103.
<label>is a program label within the function. The value of St ackOf f set _label is
the size of the stack frame at the label. The size is in 4-byte words and does not include
an implied J SR/BSR two-word stack push.
<function_name>is the function name, without a leading underscore.
High addresses
Low addresses
Incoming arguments
Return address
Outgoing arguments
Local variables
SP
and
saved registers
Stack
For example, a hel l o. c program might generate the ELF symbol sequence shown below.
In this example, the binding LOCAL means an ELF symbol binding of STB_LOCAL, the
type NOTYPE means a symbol type of STT_NOTYPE, and the section ABS means a symbol
table entry of SHN_ABS.
Example10 illustrates how these symbols might be defined in an assembly-language
program.
Example10. Generating stack unwinding symbols in assembly code
sect i on . t ext l ocal
Text St ar t _hel l o
; **************************************************************
; Exampl e f unct i on _mai n
; **************************************************************
gl obal _mai n
_mai n t ype f unc
[ push r 6
push r 7
]
DW_2
. . .
[ pop r 6
pop r 7
]
DW_5
r t s
FuncEnd__mai n
St ackOf f set __mai n equ 0 ; At _mai n sp = 0 wor ds
St ackOf f set _DW_2 equ 2 ; At DW_2 sp = 2 wor ds
St ackOf f set _DW_5 equ 0 ; At DW_5 sp = 0 wor ds
Text End_hel l o
endsec
Val ue Si ze Bi ndi ng Type Sect i on Name
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
10120h 0 LOCAL NOTYPE . t ext Text St ar t _hel l o
0h 0 LOCAL NOTYPE ABS St ackOf f set __mai n
2h 0 LOCAL NOTYPE ABS St ackOf f set _DW_2
0h 0 LOCAL NOTYPE ABS St ackOf f set _DW_5
1012Ah 0 LOCAL NOTYPE . t ext DW_2
10136h 0 LOCAL NOTYPE . t ext DW_5
10138h 0 LOCAL NOTYPE . t ext FuncEnd_mai n
10138h 0 LOCAL NOTYPE . t ext Text End_hel l o
Configuration Registers
Field Types There are several types of fields in the configuration registers.
Field with defined state
Such a field has a defined value at function entry and function exit. The compiler is free to
change the field inside a function, but it must make sure that it restores the defined state
before calling another function or before returning from the function.
In addition a compiler implementation may provide options to assume a different state of a
field. But then no compatibility exists to modules, which are compiled with the default
state.
Destroyed field
A destroyed field has no defined value at function entry and exit, but the compiler is free
to modify the field in a function. This means that the compiler must assume that a the
content of such a field will change when calling a function. the field doesnt need to be
restored before a function returns.
Field under user control
The compiler does not assume any value for such a field. Nor it does change such a field
automatically. But A compiler may provide means for reading and writing such a field,
e.g. with intrinsics. So the user can explicitly access such a field.
Status field
A status field is like a destroyed field. In contrast to a destroyed field, status fields are not
set explicitly by the compiler, but implicitly by certain instructions.
Status Register (SR) SLF, LF3, LF2, LF1, LF0
These flags must be 0 on function entry. This means a function may use all four hardware
loops.
I, OVE, DI, EXP, PE
These fields are under user control.
VF3-VF0
These fields may be destroyed by a function.
SM2
The 16-bit arithmetic saturation mode must be enabled on function entry and exit, i.e. the
SM2 bit must be 1b.
S
The scaling bit is a status bit and has not a defined value on function entry and exit.
SCM
Scaling must be disabled on function entry and exit, i.e. the scaling mode must be 00b.
RM
The rounding mode must be set to to twos-complement rounding on function entry and
exit, i.e. the RM bit must be 1b.
SM
The 32-bit arithmetic saturation mode must be enabled on function entry and exit, i.e. the
SM bit must be 1b.
It is recommended that a compiler implementation provides an option so that no saturation
is assumed.
T, C
The true and carry bits are status bit and dont have a defined value on function entry and
exit.
Exception and Mode
Register (EMR)
All fields in the EMR register are status bits or under user control. Therefore they dont
have a defined value at function entry and exit.
General
Configuration
Register (GCR)
BAM[2]
The bit 2 of the BAM field indicates the shift direction of the DOALIGN instruction. In
little endian this field must be 0b (shift right), in big endian this field must be 1b (shift left)
at function entry and exit.
BAM[1...0]
The lower 2 bits of the BAM field may be destroyed by a function. They dont have a
defined value at function entry and exit. They can be set by the SETALIGN instruction,
which is usually done before the DOALIGN instruction is executed.
Modifier Control
(MCTL) Register
The MCTL register must be 0 at function entry and exit. This defines the memory address
calculation methods for R0R7 as linear.
Hardware loops From the definition of the loop fields in SR (SLF, LF3, LF2, LF1, LF0) follows that all
hardware loop resources are available for the compilers use. As it is assumed that no
nesting occurs when entering a function, a function may use all four nesting levels for its
own use.
Static Programming Rules
Static Programming Rules
Overview The programming rules are described in the core reference manuals (CRM). Many of
these rules require a certain execution distance, or separation, between two instructions.
There are two kinds of distances used in the definition of these rules:
VLES based
Cycle based
In some cases the code sequence to be checked includes a Change Of Flow (COF)
instruction, and the rule violation candidates involves an instruction pair that one belongs
to the execution flow before the COF and the other belongs to the flow after the COF.
A COF instruction, which are of interest for the ABI are J SR, BSR and RTS. This means
that the ABI defines how the rules have to be checked around function calls and returns.
Enforce at COF
Source
The default for most programming rules is that the rule is enforced at the COF source
(before a function call and before a function return).The compiler has to make sure that the
rules are not violated, regardless of what instruction is located at the COF target (at a
function begin and after a function return).
Following rules must be enforced at the COF source:
A.1
A.2
T.1
SR.2
Enforce at COF Target For performance reasons following rule must be enforced at the COF target (at a function
begin and after a function return):
SR.4
This means that at a COF target no MOVE like instruction may be located, which reads or
writes to EMR.
Loop Rules Rules, which affect the loop registers and loop modes are not part of the ABI, because the
code, which affects a loop may not be splitted across functions and there may not be a
function call inside a loop (except the compiler is under control of the called function).
Memory Models
Memory Models
Overview A compiler implementation may provide several memory models for code and data to
generate more compact instructions for addressing. There are several ways to specify the
memory model. For example, commnd line switches can specify the memory model for all
entities in a compilation module. It is also possible that a compiler provides pragmas to
specify the memory model of separate functions or variables.
The memory models allow the compiler to generate references to global and static data
and function calls without global knowledge as to the variables or functions final
allocation address in memory. For each model, the compiler will assume that references to
global and static data and functions fit within the corresponding size implied by the model.
The expectation is that the linker will generate errors whenever a symbolic reference is
resolved to not fit within the range defined by the memory model.
Object files, which are compiled with different memory models (or contain entities with
different memory models) may be linked together. But all constraints, which are imposed
by the memory models, must be satisfied. Otherwise the linker will issue an error.
Code Memory Models There are two memory models for code entities, i.e. functions:
small: The distance between a function call and the function entry must be within 20
bits, so that a 20-bit PC-relative BSR or J SR instruction may be generated.
huge: There is no restriction on the distance between the function call and the function
entry. Therefore the compiler must generate a 32-bit absolute call.
Example11. Code memory models
; Smal l memor y model
br s >_f unc ( 2 16- bi t wor ds)
; Huge memor y model
j sr _f unc ( 3 16- bi t wor ds)
Data Memory Models Following memory models are defined for data entities, i.e. global and static variables
small: Variables must be located in the lower 64 KB of memory. This allows the use of
a short addressing mode when accessing the variables.
large: There is no restriction on the placement of variables. Therefore the compiler
must generate a 32 bit addresssing mode to access the variables.
tiny: Variables must be located in the lower 32 KB of memory. This allows to use a
MOVE.W instruction for loading the address of the data into an R-register. This
memory model is optional
tiny for small variables: For non-array variables up to a size of 8 bytes, the tiny model
is used. For array variables and variables larger that 8 bytes, the default memory model
(usually big memory) is used. This memory model is optional.
Memory Models
Example12. Data memory models
; Smal l memor y model
move. l <_var , d0 ( 2 16- bi t wor ds)
moveu. l #_var , d0 ( 3 16- bi t wor ds)
; Bi g memor y model
move. l _var , d0 ( 3 16- bi t wor ds)
moveu. l #_var , d0 ( 3 16- bi t wor ds)
; Ti ny memor y model
move. l <_var , d0 ( 2 16- bi t wor ds)
move. w #_var , d0 ( 2 16- bi t wor ds)
; Ti ny f or smal l var i abl es memor y model ( wi t h bi g memor y as def aul t )
move. l <_smal l var , d0 ( 2 16- bi t wor ds)
move. w #_smal l var , d0 ( 2 16- bi t wor ds)
move. l _l ar gevar , d0 ( 3 16- bi t wor ds)
moveu. l #_l ar gevar , d0 ( 3 16- bi t wor ds)
Memory Models
Chapter 2 High-Level Language Issues
Name Mapping
C Name Mapping Externally visible names in the C language are prefixed by an underscore (_ ) when
generating assembly language symbol names. For example, the following:
voi d t est f unc( ) {
. . .
}
generates following assembly name:
_t est f unc
C++ Name Mapping Externally visible C++language names are encoded using the rules from the generic C++
ABI, encoding known as name mangling. The external name of a C++symbol is formed
by prefixing an underscore character (_) to the mangled name of the symbol. For example,
the following:
i nt Cl ass: : member f unc( char , l ong) const {
. . .
}
generates following assembly name:
__ZNK5Cl ass10member f uncEcl
High-Level Language Issues February 2007
C System Calls
C System Calls
There are several typedefs specified in POSIX.1 which are required for system call
wrappers. These types are defined as follows for the StarCore architecture:
t ypedef unsi gned i nt mode_t ;
t ypedef l ong i nt of f _t ;
t ypedef unsi gned i nt si ze_t ;
t ypedef i nt ssi ze_t ;
t ypedef unsi gned l ong cl ock_t ;
t ypedef unsi gned l ong t i me_t ;
The following system calls must also be supported:
i nt open( const char *, i nt , . . . ) ; / / Thi r d ar g i s mode_t i f pr esent .
i nt cl ose( i nt ) ;
ssi ze_t r ead( i nt , voi d *, si ze_t ) ;
ssi ze_t wr i t e( i nt , const voi d *, si ze_t ) ;
of f _t l seek( i nt , of f _t , i nt ) ;
i nt unl i nk( const char *) ;
i nt r ename( const char *, const char *) ;
i nt access( const char *, i nt ) ;
cl ock_t cl ock( voi d) ;
t i me_t t i me( t i me_t *) ;
February 2007 High-Level Language Issues
Libraries
Libraries
The following sections provide details on support libraries.
Compiler assist
libraries
The StarCore architecture does not provide hardware support for floating-point data types,
nor for divide functionality for integer types. Compilers should provide the functionality
for some of these operations through the use of support library routines.
The functions to be provided through support library routines include the following:
Floating-point math routines
Integer divide routines
Integer modulo routines
Compilers that generate in-line code to provide these functions must make no reference to
the library functions. Compilers that provide these functions by generating function calls
to the support libraries must use the calling convention when calling them.
To ensure the ability to link code produced by different compilers into a single executable,
it is required that names of compiler support library functions match those listed in the
following sections.
Routines in support libraries must satisfy the following constraints:
Identical results must be returned when a routine is reinvoked with the same input
arguments.
Multiple calls with the same input arguments can be collapsed into a single call with a
cached result.
These properties permit a compiler to make assumptions about variable lifetimes across
library function calls: values in memory will not change, previously dereferenced pointers
need not be referenced again.
Libraries
setjmp and longjmp
layout
In the following the memory layout of the j mp_buf is shown for the ABI 4 calling
conventions.
In the following the memory layout of the j mp_buf is shown for the ABI 2 calling
conventions.
Dynamic memory
allocation
Dynamic allocations are implemented using a heap structure managed by the standard
library functions mal l oc( ) and f r ee( ) . The heap shall be allocated statically by the
linker. All addresses returned by mal l oc( ) shall be at least 8-byte aligned.
t ypedef i nt j mp_buf [ 12] ;
Offset Saved register Offset Saved register
Little-endian + 0 D4 Big-endian + 0 D4
+ 4 D5 + 4 D5
+ 8 D6 + 8 D6
+ 12 D7 + 12 D7
+ 16 R4 + 16 R4
+ 20 R5 + 20 R5
+ 24 R6 + 24 R6
+ 28 R7 + 28 R7
+ 32 D4.e + 32 D5.e
+ 34 D5.e + 34 D4.e
+ 36 D6.e + 36 D7.e
+ 38 D7.e + 38 D6.e
+ 40 SP + 40 SP
+ 44 Return address + 44 Return address
t ypedef i nt j mp_buf [ 7] ;
Offset Saved register Offset Saved register
Little-endian + 0 D6 Big-endian + 0 D6
+ 4 D7 + 4 D7
+ 8 R6 + 8 R6
+ 12 R7 + 12 R7
+ 16 D6.e + 16 D7.e
+ 18 D7.e + 18 D6.e
+ 20 SP + 20 SP
+ 24 Return address + 24 Return address
Libraries
Calling conventions Some of the runtime library functions use different calling conventions than the standard
calling conventions. Following definitions of calling conventions are used in the
subsequent list of runtime functions:
STD
The standard calling convention.
INTREG2
The standard calling convention, except hardware loop usage and the set of caller/callee
saved registers: only registers D0 and D1 are caller saved, i.e. destoyed by the runtime
function. Registers D2.HL to D4.HL are saved by the runtime function, whereas D2.E to
D4.E are sign extended or saved by the runtime function (just like D6 and D7).
Only one level of hardware loop (level 3) may be used by the runtime function.
FCMP
The standard calling convention, except the return value: The boolean return value is
returned in the t-bit.
DARG2
The standard calling convention, except hardware loop usage and parameter and return
value passing: the parameters and return values are 64 bit values. The first parameter is
passed in d0,d1. The second parameter in d2,d3. The return value is passed in d0,d1. The
most significant 32 bits are passed sign extended in the lower register, the least significant
32 bits are passed zero extended in the higher register.
Only one level of hardware loop (level 3) may be used by the runtime function.
DCMP
The DARG2 calling convention, except the return value: The boolean return value is
returned in the t-bit.
Notation The routine interfaces are shown in C prototype notation. The routine names are C-names.
This means that the routine assembler symbol names can be derived by adding a single
underscore.
For some routines there exist aliased names. A library has to provide all alternative names
for a routine. Alternative names are denoted by a separating vertical bar (|).
Floating-point
routines
Conformant library support must include the following floating point routines.
Libraries
The data formats are as specified in IEEE-754. The math routines are not required to
compute results as specified in IEEE-754. Implementation of these routines must
document the degree to which operations conform to the IEEE standard. Not all users of
floating point require IEEE-754 precision and exception handling, and may not want to
incur the overhead that complete conformance requires.
i nt _d_dt oi ( doubl e a) Calling convention: STD
Converts the double precision value of a to a signed integer by truncating
any fractional part, and returns the signed integer value.
doubl e _d_i t od( i nt a) Calling convention: STD
Converts the signed integer value of a to double precision, and returns the
double precision value.
unsi gned i nt _d_dt ou( doubl e a) Calling convention: STD
Converts the double precision value of a to an unsigned integer by
truncating any fractional part, and returns the unsigned integer value.
doubl e _d_ut od( unsi gned i nt a) Calling convention: STD
Converts the unsigned integer value of a to double precision, and returns
the double precision value.
f l oat _d_dt of ( doubl e a) Calling convention: STD
Converts the double precision value of a to single precision, and returns
the single precision value.
doubl e _d_f t od( f l oat a) Calling convention: STD
Converts the single precision value of a to double precision, and returns
the double precision value.
doubl e _d_mul ( doubl e a, doubl e b) Calling convention: DARG2
Returns a * b, computed to double precision.
doubl e _d_di v( doubl e a, doubl e b) Calling convention: DARG2
Returns a/ b, computed to double precision.
doubl e _d_add( doubl e a, doubl e b) Calling convention: DARG2
Ret ur ns a + b, comput ed t o doubl e pr eci si on.
doubl e _d_sub( doubl e a, doubl e b) Calling convention: DARG2
Returns a - b, computed to double precision.
doubl e _d_usub( doubl e a) Calling convention: STD
Returns the negated double precision value a.
i nt _d_f t oi | __QFl oat ToI nt 32s( f l oat a) Calling convention: STD
Converts the single precision value of a to a signed integer by truncating
any fractional part, and returns the signed integer value.
f l oat _d_i t of | __QI nt 32sToFl oat ( i nt a) Calling convention: STD
Converts the signed integer value of a to single precision, and returns the
single precision value.
unsi gned i nt _d_f t ou| __QFl oat ToI nt 32u( f l oat a) Calling convention: STD
Converts the single precision value of a to an unsigned integer by
truncating any fractional part, and returns the unsigned integer value.
Libraries
f l oat _d_ut of | __QI nt 32uToFl oat ( unsi gned i nt a) Calling convention: STD
Converts the unsigned integer value of a to single precision, and returns
the single precision value.
f l oat _f _mul | __QFMul ( f l oat a, f l oat b) Calling convention: STD
Returns a * b, computed to single precision.
f l oat _f _di v| __QFDi v( f l oat a, f l oat b) Calling convention: STD
Returns a/ b, computed to single precision.
f l oat _f _add| __QFAdd( f l oat a, f l oat b) Calling convention: STD
Returns a + b, computed to single precision.
f l oat _f _sub| __QFSub( f l oat a, f l oat b) Calling convention: STD
Returns a - b, computed to single precision.
i nt _d_f eq( doubl e a, doubl e b) Calling convention: DCMP
Performs an unordered comparison of the double precision values of a
and b. Returns a 1 if they are equal, and a 0 otherwise.
i nt _d_f ge( doubl e a, doubl e b) Calling convention: DCMP
Performs an ordered comparison of the double precision values of a and
b. Returns a 1 if a is greater than or equal to b, and a 0 otherwise.
i nt _d_f gt ( doubl e a, doubl e b) Calling convention: DCMP
b. Returns a 1 if a is greater than b, and a 0 otherwise.
i nt _d_f l e( doubl e a, doubl e b) Calling convention: DCMP
b. Returns a 1 if a is less than or equal to b, and a 0 otherwise.
i nt _d_f l t ( doubl e a, doubl e b) Calling convention: DCMP
b. Returns a 1 if a is less than b, and a 0 otherwise.
i nt _d_f ne( doubl e a, doubl e b) Calling convention: DCMP
Performs an unordered comparison of the double precision values of a
and b. Returns a 1 if they are unordered or not equal; returns a 0
otherwise.
i nt _f _f eq| __QFCmpeq( f l oat a, f l oat b) Calling convention: FCMP
Performs an unordered comparison of the single precision values of a and
b. Returns a 1 if they are equal, and a 0 otherwise.
i nt _f _f ge| __QFCmpge( f l oat a, f l oat b) Calling convention: FCMP
Performs an ordered comparison of the single precision values of a and b.
Returns a 1 if a is greater than or equal to b, and a 0 otherwise.
i nt _f _f gt | __QFCmpgt ( f l oat a, f l oat b) Calling convention: FCMP
Returns a 1 if a is greater than b, and a 0 otherwise.
i nt _f _f l e| __QFCmpl e( f l oat a, f l oat b) Calling convention: FCMP
Returns a 1 if a is less than or equal to b, and a 0 otherwise.
Libraries
i nt _f _f l t | __QFCmpl t ( f l oat a, f l oat b) Calling convention: FCMP
Returns a 1 if a is less than b, and a 0 otherwise.
i nt _f _f ne| __QFCmpne( f l oat a, f l oat b) Calling convention: FCMP
Performs an unordered comparison of the single precision values of a and
b. Returns a 1 if they are unordered or not equal; returns a 0 otherwise.
Libraries
Integer and fractional
arithmetic routines
Conformant library support must include the following integer and fractional arithmetic
routines. These routines have no side effects.
shor t __di v16| __Qdi v16_s( shor t a, shor t b) Calling convention: INTREG2
Returns the value of a/ b. If the divisor has the value zero, the behavior is
undefined.
i nt __udi v16| __Qdi v16_u( unsi gned shor t a, unsi gned shor t b) Calling
convention: INTREG2
Returns the unsigned value of a/ b. If the divisor has the value zero, the
behavior is undefined.
i nt __di v32| __Qdi v32_s( l ong a, l ong b) Calling convention: INTREG2
Returns the value of a/ b. If the divisor has the value zero, the behavior is
undefined.
i nt __udi v32| __Qdi v32_u( unsi gned l ong a, unsi gned l ong b) Calling
convention: INTREG2
Returns the unsigned value of a/ b. If the divisor has the value zero, the
i nt __r em16| __Qmod16_s( shor t a, shor t b) Calling convention: INTREG2
Returns the remainder upon dividing a by b. If the divisor has the value
zero, the behavior is undefined.
i nt __ur em16| __Qmod16_u( unsi gned shor t a, unsi gned shor t b) Calling
convention: INTREG2
Returns the unsigned remainder upon dividing a by b. If the divisor has
the value zero, the behavior is undefined.
i nt __r em32| __Qmod32_s( l ong a, l ong b) Calling convention: INTREG2
Returns the remainder upon dividing a by b. If the divisor has the value
i nt __ur em32| __Qmod32_u( unsi gned l ong a, unsi gned l ong b) Calling
convention: INTREG2
Returns the unsigned remainder upon dividing a by b. If the divisor has
the value zero, the behavior is undefined.
shor t _di v_s( shor t a, shor t b) Calling convention: INTREG2
Returns the value of the fractional divide a/ b. If the divisor has the value
Libraries
Optional long long
routines
If the optional C l ong l ong data type is supported, then library support must also include
the following l ong l ong integer routines.
l ong l ong _SDi v64( l ong l ong a, l ong l ong b) Calling convention: DARG2
Computes the quotient a/ b, truncating any fractional part, and returns the
signed l ong l ong result. If the divisor has the value zero, the behavior is
undefined.
unsi gned l ong l ong _UDi v64( unsi gned l ong l ong a, unsi gned l ong
l ong b) Calling convention: DARG2
Computes the quotient a/ b, truncating any fractional part, and returns the
unsigned l ong l ong result. If the divisor has the value zero, the
l ong l ong _SRem64( l ong l ong a, l ong l ong b) Calling convention: DARG2
Computes the remainder upon dividing a by b, and returns the signed
l ong l ong result. If the divisor has the value zero, the behavior is
undefined.
l ong l ong _Mul t _64( l ong l ong a, l ong l ong b) Calling convention: DARG2
Multiplies a by b, and returns the signed l ong l ong result.
unsi gned l ong l ong _UMul t _64( unsi gned l ong l ong a, unsi gned l ong
Multiplies a by b, and returns the unsigned l ong l ong result.
unsi gned l ong l ong _URem64( unsi gned l ong l ong a, unsi gned l ong
Computes the remainder upon dividing a by b, and returns the unsigned
l ong l ong result. If the divisor has the value zero, the behavior is
undefined.
l ong l ong _d_dt ol l ( doubl e a) Calling convention: STD
Converts the double precision value of a to a signed l ong l ong by
truncating any fractional part, and returns the signed l ong l ong value.
unsi gned l ong l ong _d_dt oul l ( doubl e a) Calling convention: STD
Converts the double precision value of a to an unsigned l ong l ong by
truncating any fractional part, and returns the unsigned l ong l ong
value.
doubl e _d_l l t od( l ong l ong a) Calling convention: STD
Converts the signed l ong l ong value of a to a double precision value,
and returns the double precision value.
doubl e _d_ul l t od( unsi gned l ong l ong a) Calling convention: STD
Converts the unsigned l ong l ong value of a to a double precision value,
and returns the double precision value.
l ong l ong _d_f t ol l ( f l oat a) Calling convention: STD
Converts the single precision value of a to a signed l ong l ong by
truncating any fractional part, and returns the signed l ong l ong value.
Libraries
unsi gned l ong l ong _d_f t oul l ( f l oat a) Calling convention: STD
Converts the single precision value of a to an unsigned l ong l ong by
truncating any fractional part, and returns the unsigned l ong l ong
value.
f l oat _d_l l t of ( l ong l ong a) Calling convention: STD
Converts the signed l ong l ong value of a to a single precision value,
and returns the single precision value.
f l oat _d_ul l t of ( unsi gned l ong l ong a) Calling convention: STD
Converts the unsigned l ong l ong value of a to a single precision value,
and returns the single precision value.
Register saving and
restoring functions
The library must contain functions for saving and restoring the function context. These
functions may be used by the compiler instead of PUSH and POP instructions to reduce
code size. The following functions are used for the ABI 4 calling conventions.
voi d __abi 4_cal l ee_save( voi d)
Must be called at the beginning of a function. The registers D4, D5, D6,
D7, R4, R5, R6 and R7 are pushed on the stack. After this function
returns, the stack pointer is increased by 32 bytes.
voi d __abi 4_cal l ee_r est or e( voi d)
This function must be the target of a BRA or J MP instruction at the end of
a function. It restores the callee-saved registers D4, D5, D6, D7, R4, R5,
R6 and R7 and returns through the caller return address stored at SP 40.
There is no need for an RTS after calling the restoring function, since it
returns automatically for the caller.
After calling the saving function __abi 4_cal l ee_r est or e, the stack frame values
relative to the address in the stack pointer (SP) will be:
Note The assembler names of the save and restore functions have three leading
underscores.
D5
D4
R5
R4
R7
R6
24
20
16
12
8
4
SP
D7
D6
SR
28
32
36
40
Return address
Libraries
The following functions are used for the ABI 2 calling conventions.
voi d __CW_SC100_cal l ee_save( voi d)
Must be called at the beginning of a function. The registers D6, D7, R6
and R7 are pushed on the stack. After this function returns, the stack
pointer is increased by 16 bytes.
voi d __CW_SC100_cal l ee_r est or e( voi d)
This function must be the target of a BRA or J MP instruction at the end of
a function. It restores the callee-saved registers D6, D7, R6 and R7 and
returns through the caller return address stored at SP 24. There is no
need for an RTS after calling the restoring function, since it returns
automatically for the caller.
After calling the saving function __CW_SC100_cal l ee_r est or e, the stack frame
values relative to the address in the stack pointer (SP) will be:
Example13. Saving and restoring functions usage example
_f oo:
bsr ___CW_SC100_cal l ee_save ; Save cal l ee- saved r egi st er s.
adda #f r ame_si ze_f oo, sp ; Adj ust SP by f r ame si ze.
_f oo_body:
. . .
_f oo_body_end:
suba #f r ame_si ze_f oo, sp ; Adj ust SP by f r ame si ze.
br a ___CW_SC100_cal l ee_r est or e ; Rest or e cal l ee- saved r egi st er s
; and r et ur n t o cal l er of f oo.
C++ Support
Functions
The StarCore C++ABI is based on the generic C++ABI. A conforming runtime library
shall implement the functions and classes required by the C++standard and the generic
ABI.
In addition to those classes, a C++StarCore runtime library should implement the
following functions:
ext er n C voi d *__vl a_al l oc( si ze_t si ze)
Allocates a gcc/C99-style variable length array. Returns a pointer to that
arrray.
ext er n C voi d __vl a_f r ee( voi d *pt r )
Frees memory for a variable length array previously allocated using
__vla_alloc.
R7
R6
D7
D6
SR
Return address
24
20
16
12
8
4
SP
Libraries
ext er n C voi d *__cl ear ( voi d *pt r , si ze_t si ze) ;
Sets the contents of the memory area pointed by ptr to zero. The second
argument contains the size of the memory to be cleared in bytes. The pointer is
not necessary aligned. No action is taken if the pointer is NULL.
ext er n "C" voi d *__r egi st er _gl obal _obj ect ( )
ext er n "C" voi d __dest r oy_gl obal _chai n( )
These functions are used for destroying global objects before exiting the
program. See the section 3.8.2 for a detailed description of those functions.
ext er n "C" voi d __t hr ow( )
ext er n "C" voi d __r et hr ow( )
ext er n "C" voi d __end_cat ch( )
ext er n "C" voi d __unexpect ed( )
These functions are used for C++ exception handling.
C++ ABI
C++ ABI
Overview The reference base standard for the C++ABI is the generic C++ABI summarized below.
This section documents StarCore-specific deviations from the generic standard. The
Exception Handling ABI is not based on the generic C++ABI and it is documented
separately.
The generic C++ABI (originally developed for SVr4 on Itanium) specifies:
The layout of C++non-POD class types in terms of the layout of POD types. (2: Data
Layout, sections 2.1-2.8). The layout of POD types is the same as the layout of C types,
described in this ABI in sections 2.3 and below.
The content of run-time type information (RTTI). (2.9 Run-Time Type Information)
How class types requiring copy construction are passed as parameters and results. (3:
Function Calling Conventions and APIs, Sections 3.1-3.2)
Necessary APIs for object construction and destruction. (3.3 Construction and
Destruction APIs)
How names with linkage are mangled (name mangling). (5.1 External Names)
The chapter and section numbers above refer to the generic C++ABI.
The differences between the StarCore C++ABI and the generic C++ABI are documented
below.
Controlling Object
Construction Order
The #pragma priority (as documented in section 3.3.4 of the generic ABI) is not required.
DSO Object
Destruction API
The StarCore compiler uses proprietary functions for object destruction. These functions
are semantically equivalent with the generic ABI functions, but they should not be called
from user code. These functions are:
__r egi st er _gl obal _obj ect instead of __cxa_at exi t
__dest r oy_gl obal _chai n instead of __cxa_f i nal i ze
After constructing a global (or local static) object, that will require destruction on exit, a
termination function is registered as follows:
ext er n "C" voi d __r egi st er _gl obal _obj ect ( voi d *obj ect , voi d
( *dest r uct or ) ( voi d *) , voi d * memor y)
This registration, e.g. __r egi st er _gl obal _obj ect ( o, d, memor y) , is intended to
cause the call d( o) when the program exits, before all such termination calls registered
before this one. The registration function is not called from within the constructor. The
third parameter (memory) is a pointer to a preallocated memory space, usually in the
static data area, that can hold a structure containing three pointers (12 bytes, aligned at a 4-
byte boundary).
The termination function must be called when the program exists normally (via an exit()
call or when the function main returns):
ext er n "C" voi d __dest r oy_gl obal _chai n( voi d)
C++ ABI
The C runtime library may have a separate implementation for at exi t ( ) .
Demangler API The function __cxa_demangle is not required.
Exception Handling The StarCore exception handling is a table based implementation which is not compatible
with the high level generic C++ABI specification.
External Names The external name of a C++symbol is formed by prefixing an underscore character (_) to
the mangled name of the symbol, as specified by the generic C++ABI.
Vague Linkage Vague linkage applies to C++objects are not clearly part of a single object file, but are
required to have a single definition. The compiler should assign a STB_MULTIDEF
symbol binding to such objects.
Multidef symbols resemble global symbols, but having multidef symbols with the same
name in different module does not generate an error. The linker keeps only the object
associated to the first symbol, in link order.
C++ ABI
Chapter 3 Object File Format
The executable and linking format (ELF) is used for representing the binary application to
the system. For a complete description of ELF, refer to the Tools Interface Standards (TIS)
Executable and Linking Format (ELF) Specification, Version 1.1. This chapter highlights
differences between the ELF version 1.1 definition and the StarCore implementation.
This chapter focuses on the interface for relocatable and executable programs. A
relocatable program contains code suitable for linking to create another relocatable
program or executable program. An executable program contains binary information
suitable for loading and execution on a target processor.
Interface Descriptions
ELF presents two views of binary data, as shown in Figure2:
The linking view provides data in a format suitable for incremental linking into a
relocatable file or final linking to an executable file.
The execution view provides binary data in a format suitable for loading and execution.
An ELF header is always present in either view of the ELF file. For the linking view,
sections are the main entity in which information is presented. A section header table
provides information for interpretation and navigation for each section. For the execution
view, segments are the primary sources of information. Sections may be present but are
not required. A program header table provides information for interpretation and
navigation through each segment. For exact details, see the ELF version 1.1 specification.
Figure 2. Object file format
Linking view Execution view
Elf header
Elf header
Optional program header Program header
Segments Sections
... ...
Section header table Optional section header table
Object File Format February 2007
The ELF Header
The ELF Header
The ELF header structure is shown in Example14. This structure and its fields are defined
by the ELF version 1.1 specification. StarCore-specific code is shown in Example15.
Example14. ELF header structure
t ypedef st r uct {
unsi gned char e_i dent [ EI _NI DENT] ;
El f 32_Hal f e_t ype;
El f 32_Hal f e_machi ne;
El f 32_Wor d e_ver si on;
El f 32_Addr e_ent r y;
El f 32_Of f e_phof f ;
El f 32_Of f e_shof f ;
El f 32_Wor d e_f l ags;
El f 32_Hal f e_ehsi ze;
El f 32_Hal f e_phent si ze;
El f 32_Hal f e_phnum;
El f 32_Hal f e_shent si ze;
El f 32_Hal f e_shnum;
El f 32_Hal f e_shst r ndx;
} El f 32_Ehdr ;
Example15. StarCore specifics
e_i dent [ EI _CLASS] = ELFCLASS32
e_i dent [ EI _DATA] = ELFDATA2LSB ( l i t t l e- endi an memor y mode)
e_i dent [ EI _DATA] = ELFDATA2MSB ( bi g- endi an memor y mode)
e_machi ne: 0x3a ( EM_STARCORE)
The e_f l ags field is used to distinguish object files translated for different cores features,
different core revisions, and different ABI versions. The e_f l ags field is split into three
parts:
Bits 0-5: The core features. The defined core features are:
#def i ne EF_STARCORE_CORE_4_MAC 0
Mixing object files with with different code features will result in an object file with the
highest number of MAC units. For example, mixing EF_STARCORE_CORE_2_MAC and
EF_STARCORE_CORE_4_MAC will result in an object file with
EF_STARCORE_CORE_4_MAC.
Bits 6-11: The revision of the used core architecture. The defined core revisions are:
#def i ne EF_STARCORE_CORE_REV_UNKNOWN 0
#def i ne EF_STARCORE_CORE_REV_SC1000_V2 2
#def i ne EF_STARCORE_CORE_REV_SC140E_V3 3
Mixing object files with different core architectures will result in an object file with the
highest core architecture value.
Bits 12-17: The ABI version. The defined ABI versions are:
February 2007 Object File Format
The ELF Header
#def i ne EF_STARCORE_ABI _PREABI 0
#def i ne EF_STARCORE_ABI _NONCONFORMI NG 1
#def i ne EF_STARCORE_ABI _2_0 2
Linking with different ABI versions or with non-conforming object files may result in
linker errors or undetermined output.
Bits 18-31: Zero. Reserved for future use.
Example16. Definition of macros for accessing e_flag parts
#def i ne ELF32_EF_STARCORE_CORE( e_f l ags) ( ( e_f l ags) & 0x3f )
#def i ne ELF32_EF_STARCORE_REV( e_f l ags) ( ( ( e_f l ags) >> 6) & 0x3f ) )
#def i ne ELF32_EF_STARCORE_ABI ( e_f l ags) ( ( ( e_f l ags) >> 12) & 0x3f ) )
#def i ne ELF32_EF_STARCORE( cor e, r ev, abi ) \
( ( ( cor e) & 0x3f ) | ( ( ( r ev) & 0x3f ) << 6) | ( ( ( abi ) & 0x3f ) << 12) )
Sections
Sections
Sections are the main components of the ELF file. Section headers define all the
information about a section. A section header is shown in Example17. It is identical to the
ELF version 1.1 definition.
Example17. Section header structure
t ypedef st r uct {
El f 32_Wor d sh_name;
El f 32_Wor d sh_t ype;
El f 32_Wor d sh_f l ags;
El f 32_Addr sh_addr ;
El f 32_Of f sh_of f set ;
El f 32_Wor d sh_si ze;
El f 32_Wor d sh_l i nk;
El f 32_Wor d sh_i nf o;
El f 32_Wor d sh_addr al i gn;
El f 32_Wor d sh_ent si ze;
} El f 32_Shdr ;
Sections
Sections used in StarCore ELF binaries are listed in Table6. The section names listed in
this table are case sensitive and are reserved for the system.
Table 6. StarCore ELF sections
Name (sh_name) Type (sh_type) Flags (sh_flags) Purpose
. t ext SHT_PROGBI TS SHF_ALLOC, SHF_EXECI NSTR Executable instructions
. dat a SHT_PROGBI TS SHF_ALLOC, SHF_WRI TE Initialized data
. r odat a SHT_PROGBI TS SHF_ALLOC Read-only, initialized data
. zdat a SHT_PROGBI TS SHF_ALLOC, SHF_WRI TE Zero Data Area initialized data
. bss SHT_NOBI TS SHF_ALLOC, SHF_WRI TE Uninitialized data
1
. zbss SHT_NOBI TS SHF_ALLOC, SHF_WRI TE Zero Data Area uninitialized data
1
. r el asection SHT_RELA None Relocation info for sect i on
2
. symt ab SHT_SYMTAB None Symbol table
. shst r t ab SHT_STRTAB None Section name string table
. st r t ab SHT_STRTAB None General purpose string table
. not e SHT_NOTE None File identification
3
. debug_abbr ev SHT_PROGBI TS None Abbreviation tables
4
. debug_ar anges SHT_PROGBI TS None Address range tables
4
. debug_f r ame SHT_PROGBI TS None Call frame information
4
. debug_i nf o SHT_PROGBI TS None Debugging information entries
4
. debug_l i ne SHT_PROGBI TS None Line number information
4
. debug_l oc SHT_PROGBI TS None Location lists
4
. debug_maci nf o SHT_PROGBI TS None Macro information
4
. debug_pubnames SHT_PROGBI TS None Global name tables
4
. SC100. del ay_sl ot s SHT_PROGBI TS None Static delay slot information
5
1
The contents of the .bss and .zbss sections are zeroed when loaded.
2
See Relocation on page 72.
3
See NOTE Section on page 91.
4
This information is in DWARF2 format.
5
See Special Sections on page 68.
Special Sections
Special Sections
.SC100.delay_slots A debug section called . SC100. del ay_sl ot s is used to hold all static delay slot
information for each StarCore executable file. Assemblers must identify and generate
sufficient relocatable file information (sections and relocation entries) to support this
feature; linkers should need no special knowledge of this feature when creating executable
files. Assemblers must also populate this section when creating executable files in
absolute mode.
The . SC100. del ay_sl ot s section uses DWARF2 definitions like those used in the
. debug_l i ne section, and consists of an unpadded sequence of opcodes with zero or
more operands. No special headers, padding, alignment, or sequence terminators are
required.
Opcodes are represented by a single unsigned byte (8 bit) value. To accommodate future
expansion without breaking existing readers, 4 bits are used for a unique ID (provides 16
opcodes) and 4 bits are used to indicate the size in bytes for the operands (provides up to
15 bytes of operands).
Three opcode IDs are initially required; additional IDs may be added later to support such
features as overlays and position independent code. The required opcode IDs are:
SDS_EXPLI CI T_OP (explicit delayed instructions, for example, J SRD).
Accepts two unsigned word (32 bits) operands. The first is the address of the explicit
Variable Length Execution Set (VLES), and the second is the address of the delay slot
VLES.
SDS_LONGLOOP_OP (last two VLESes of a long loop).
Accepts three unsigned word (32 bits) operands. The first is the address of the lpmark
VLES, the second is the address of the next VLES, and the third is the address of the
last VLES in the loop.
SDS_SHORTLOOP_OP (last VLES of a short loop).
Accepts two unsigned word (32 bits) operands. The first is the address of the first
VLES, and the second is the address of the last (second) VLES in the loop.
Each opcode with operands is intended to completely describe all information potentially
needed to implement features or checks that any debugger may reasonably expect to
perform. This includes the static delay slot type, the addresses of the VLES immediately
before the delay slot, and the address of each VLES in a static delay slot.
Debuggers need simply walk the byte stream (opcode then operands) of the
. SC100. del ay_sl ot s section until all data is exhausted.
Example18 and Example19 define the opcode IDs and the macros for accessing opcode
parts.
Example18. Definition of opcode IDs
#def i ne SDS_EXPLI CI T_OP 0
#def i ne SDS_LONGLOOP_OP 1
#def i ne SDS_SHORTLOOP_OP 2
Special Sections
Example19. Definition of macros for accessing opcode parts
#def i ne SDS_I D( opcode) ( ( ( opcode) >> 4) & 0xf )
#def i ne SDS_SI ZE( opcode) ( ( opcode) & 0xf )
#def i ne SDS_OPCODE( i d, si ze) ( ( ( si ze) & 0xf ) | ( ( ( i d) & 0xf ) << 4) )
.mw_info The section .mw_info is generated by the assembler and is used by the linker for the
following purposes:
Identification of candidates for dead-data stripping.
Identification of rom init table sections.
The section is composed of variable size records each starting with an 8 byte prefix
holding 2 fields:
An unsigned 32-bit value representing the entry's length.
An unsigned 8-bit value representing the type.
Currently only records of type 0 are supported. Type 0 records continue with:
An unsigned 8-bit value representing the alignment
An unsigned 8-bit value representing the subtype 1 - variable , 2- initializer)
An unsigned 32-bit value representing the symbol index.
and are used by the linker to identify variable and rom initialization areas candidate for
dead-data stripping

Example:
l ab1 t ype I NI TI ALI ZER
l ab2 t ype VARI ABLE

sect i on i ni t _t abl e_0
; PRAGMA sect ype i ni t _t abl e
dcl 0
endsec

hexadecimal section content:
0b 00 00 00 00 f f 02 06 00 00 00
0b 00 00 00 00 f f 01 07 00 00 00

The elf type of .mw_info is SHT_MW_INFO=SHT_LOPROC+3
.rom_init_tables The .rom_init_tables section is used in the startup file to copy (from ROM to RAM)
variable initial values (when -mrom scc command line option is used).
Linker generates .rom_init_tables section (SHT_PROGBITS, SHF_ALLOC) and a
__rom_init_tables global symbol to point to the beginning of this section.
The table contains the addresses and the sizes of init table sections.
Special Sections
The .rom_init_tables section starts with a vector of 8-byte entries - one for each relevant
section:
4 bytes hold the section address.
4 bytes that hold section size.
And ends with the suffix (8 bytes appears once, at the end):
4 byes of -1
and another 4 bytes of -1.
The elf type of .rom_init_table is SHT_PROGBITS.
.bsstab The linker automatically creates the .bsstab section, which contains these symbols:
__bss_table an array of type Elf32_bsstab (see below) that contains an entry for each
section of SHT_nobits type excluding the sections mentioned in the LCF .no_init
directive.
__bss_count the number of entries in __bss_table; an unsigned, 32-bit
integer.
The .bsstab section starts with a vector of 8-byte entries - one for each relevant section
(the low 4 bytes hold the section address, the high 4 bytes hold the section size) and ends
with 4 bytes holding the number of the entries.
The startup file uses these symbols to fill the .bss sections with zeros.
The structured type Elf32_bsstab is:
t ypedef st r uct {
El f 32_Addr st ar t _addr ess; / *st ar t addr ess of . bss sect i on*/
ELF32_Wor d l engt h; / *si ze of . bss sect i on i n byt es*/
}El f 32_bsst ab;
The elf type of .bsstab is SHT_PROGBITS.
.ovltab . The linker creates a section .ovltab wherever overlay sections are involved. This section
contains two symbols __overlay_table and __overlay_count, where:
__overlay_table is an array of type Elf32_Ovl (see below), that contains an entry for each
overlay section.
__overlay_count is an unsigned 32-bit integer, that represents the number of entries in
__overlay_table.
t ypedef st r uct {
El f 32_Addr ovl _r un; / *over l ay r un addr ess*/
El f 32_Addr ovl _l oad; / *over l ay l oad addr ess*/
El f 32_Wor d ovl _si ze; / *si ze i n byt es of t he over l ay sect i on*/
El f 32_Wor d ovl _checksum; / *checksumof t he over l ay dat a*/
El f 32_Wor d ovl _f l ags; / *over l ay f l ags, used by t he over l ay manager */
El f 32_Wor d ovl _ot her ; / *ot her i nf or mat i on*/
El f 32_Hal f ovl _shndx; / *over l ay sect i on i ndex*/
El f 32_Hal f ovl _par ent ; / *par ent over l ay*/
El f 32_Hal f ovl _si bl i ng; / *next si bl i ng over l ay*/
El f 32_Hal f ovl _chi l d; / *f i r st chi l d over l ay*/
Special Sections
} El f 32_Ovl ;
where:
Elf32_Addr is a 32-bit unsigned value.
Elf32_Word is a 32-bit integer value.
Elf32_Half is a 16-bit integer value.
The .ovltab is a section when is stored the following objects in this order: _overlay_table[]
and _overlay_count.
The size of __overlay_table is number of entry * sizeof(Elf32_Ovl).
The size of __overlay_count is 4.
Linker creates the .ovltab section only if the __overlay_table symbol is referenced.
An undefined reference to __overlay_table symbol prevents the linker from dead
stripping and in this case linker creates the .ovltab section.
The elf type of .ovltab is SHT_STARCORE_OVLTAB.
Relocation
Relocation
Each section which contains relocatable data has a corresponding relocation section of
type SHT_RELA. The sh_i nf o field of the relocation section defines the section header
index of the section (henceforth referred to as the data section) to which the relocations
apply. The sh_l i nk field of the relocation section defines the section header index of the
associated symbol table. If section names are used, the name of the relocation section is
. r el a prepended to the name of the data section.
A relocation entry is defined by the El f 32_Rel a structure and associated macros as
shown in Example20. The r _of f set field defines an offset into the data section to which
the individual relocation applies. The r _i nf o field specifies both the type of the
relocation and the symbol used in computation of the relocation data.
The relocation type is extracted from the r _i nf o field using the ELF32_R_TYPE macro
and the symbol number is extracted using the ELF32_R_SYMmacro. The r _i nf o field is
synthesized from the relocation type and symbol number using the ELF32_R_I NFO
macro.
In the remainder of this section, the relocation value is the value to be stored at the
location defined by the r _of f set field (in the format specified by the relocation type).
For a relocation type in Table7, the relocation value is computed by adding the signed
value of the r _addend field to the value of the symbol indicated by the symbol number.
Symbol number zero is treated as absolute zero, in which case the relocation value is
simply the value of the r _addend field. This degenerate case is also often used by the
extended relocation types defined in Relocation stack on page86, particularly
R_STARCORE_OPER and R_STARCORE_POP, for which a symbol value is rarely useful.
Example20. Relocation entry defined with Elf32_Rela
t ypedef st r uct {
El f 32_Addr r _of f set ;
El f 32_Wor d r _i nf o;
El f 32_Swor d r _addend;
} El f 32_Rel a;
#def i ne ELF32_R_SYM( i ) ( ( i ) >>8)
#def i ne ELF32_R_TYPE( i ) ( ( i ) &0xf f )
#def i ne ELF32_R_I NFO( s, t ) ( ( ( s) <<8) | ( ( t ) &0xf f ) )
Relocation types Device-specific relocations describe how a memory location should be patched by the
linker. An ordinary relocation encodes exactly one instruction operand (or, in the case of
data relocations, exactly one data value). It is the responsibility of the linker to ensure that
the operand meets the range and alignment requirement specified by the relocation.
For each relocation type in Table7, the Type field indicates the value extracted using
ELF32_R_TYPE, both as a number and as a standard C preprocessor symbol. A brief
abstract of the relocation follows in parentheses.
The Size field indicates the number of bits used to represent the relocation value. If the
operand range is a subset of the values which can be represented in these bits, that
restriction is indicated in parentheses.
Relocation
The Signedness field indicates whether the relocation value is treated as signed or
unsigned.
The Alignment field indicates the alignment requirement in bits of the relocation value.
This is the number of least significant bits in the relocation value which must be zero.
The Shift field indicates the number of bits the relocation value is right-shifted before it is
encoded. The shift count subtracted from the size is the number of bits used to encode the
relocation value.
The Overflow field indicates whether the relocation type checks the relocation value for
overflow. A calculated relocation value can be larger than the intended field, and the
relocation type can verify the value range or truncate the result. In case of verify a
relocation value has to be in range otherwise an error message is issued. Truncation
simply cuts off the exceeding bits and fits the result into the intended field, while issuing a
warning message. Note that an overflow can not occur for 32 bit relocations, because the
internal representation of symbol values is 32 bit.
The Special field indicates any other special processing performed during relocation. For
instructions which compute the PC, the value of the PC is the address of the instruction to
which the relocation applies (computed by adding the relocation's r _of f set field and the
data section's sh_addr field), not the machine's runtime PC value (see Instruction
address vs. VLES address on page89).
The Encoding field indicates the way the relocation value is encoded in the target memory
locations. The order of the bits in the instruction operand or data value encoding does not
necessarily match the order of the bits in the relocation value. Upper case letters are used
to indicate relocation value bits which are more significant than bits indicated by lower
case letters. s and S denote bits of a signed relocation value, u and U denote bits of an
unsigned relocation value, and x denotes a bit of a relocation value that is either signed or
unsigned. Dashes indicate bits not changed by the relocation. All encodings for
instructions are shown in groups of 16 bits; the bits within each group are subject to byte-
swapping depending on target endianness. Relocation types 2 and 3 (16-bit and 32-bit
direct) are also endianness-sensitive.
The Applies To field indicates which instructions or directives generate this relocation.
Example:
- - - - S- - - sss- - SSS - - - ssssssssssssS
1 111 111 1198765432101
9 432 876 10 5
Left to right, the Ss represent bits 1915 and the ss represent bits 140 of the relocation
value. For a big-endian target, this corresponds to a byte representation of:
byt e 0 byt e 1 byt e 2 byt e 3
- - - - S- - - sss- - SSS - - - sssss sssssssS
1 111 111 11987 65432101
9 432 876 10 5
For a little-endian target, this corresponds to a byte representation of:
byt e 0 byt e 1 byt e 2 byt e 3
sss- - SSS - - - - S- - - sssssssS - - - sssss
111 111 1 65432101 11987
432 876 9 5 10
Relocation
Table 7. Relocation type definitions
Type: 1, R_STARCORE_DI RECT_8 (8-bit direct)
Size: 8
Signedness: Either
Alignment: 0
Shift: 0
Overflow: Truncate
Encoding: xxxxxxxx
76543210
Applies to: DCB
Size: 16
Signedness: Either
Alignment: 0
Shift: 0
Overflow: Truncate
Encoding: xxxxxxxxxxxxxxxx
1111119876543210
543210
Applies to: DCW
Size: 32
Signedness: Either
Alignment: 0
Shift: 0
Overflow: Truncate
Encoding: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
33222222222211111111119876543210
1098765432109876543210
Applies to: DCL
Relocation
Type: 4, R_STARCORE_R9_1_1 (9-bit PC-relative)
Size: 9
Signedness: Signed
Alignment: 1
Shift: 1
Overflow: Verify
Encoding: - - - - - - - ssssssss-
87654321
Special: The PC is subtracted from the relocation value before any range checking or alignment checking is
performed.
Applies to: BF <label; BFD<label; BSR <label; BSRD<label; BT <label; BTD<label
Size: 11
Signedness: Signed
Alignment: 1
Shift: 1
Overflow: Verify
Encoding: - - - - - ssssssssss-
1987654321
0
performed.
Applies to: BRA <label; BRAD<label
Size: 17
Signedness: Signed
Alignment: 1
Shift: 1
Overflow: Verify
Encoding: - - - - - - - - sss- - - - - - - - ssssssssssssS
111 1119876543211
543 210 6
performed.
Applies to: BREAK label; CONT label; CONTDlabel; DOSETUPn label; SKIPLS label
Table 7. Relocation type definitions (Continued)
Relocation
Size: 21
Signedness: Signed
Alignment: 1
Shift: 1
Overflow: Verify
Encoding: - - - - S- - - sss- - SSS - - - ssssssssssssS
2 111 111 1119876543211
0 543 987 210 6
performed.
Applies to: BF >label; BFD>label; BRA >label; BRAD>label; BSR >label; BSRD>label; BT >label; BTD>label
Type: 8, R_STARCORE_S7_0_0 (7-bit signed)
Size: 7
Signedness: Signed
Alignment: 0
Shift: 0
Overflow: Verify
Encoding: - - - - - - - - - sssssss
6543210
Applies to: MOVE.W#s7,DR
Size: 15
Signedness: Signed
Alignment: 0
Shift: 0
Overflow: Verify
Encoding: - - - - - - - - - ss- - - - - - - - sssssssssssss
11 1119876543210
43 210
Applies to: MOVE.BDR,(Rn+s15); MOVE.BDR,(SP+s15); MOVE.B(SP+s15),DR; MOVEU.B(Rn+s15),DR;
MOVEU.B(SP+s15),DR
Relocation
Size: 15
Signedness: Signed
Alignment: 1
Shift: 0
Overflow: Verify
11 1119876543210
43 210
Applies to: MOVE.F (Rn+s15),Db; MOVE.F (SP+s15),Db; MOVE.WC4,(SP+s15); MOVE.WDR,(Rn+s15);
MOVE.W(Rn+s15),DR; MOVE.W(SP+s15),C4; MOVES.F Db,(Rn+s15); MOVES.F Db,(SP+s15);
MOVEU.W(Rn+s15),DR; MOVEU.W(SP+s15),C4
Size: 15
Signedness: Signed
Alignment: 2
Shift: 0
Overflow: Verify
11 1119876543210
43 210
Applies to: MOVE.L C4,(SP+s15); MOVE.L Da.E:Db.E,(SP+s15); MOVE.L DR,(Rn+s15); MOVE.L (Rn+s15),DR;
MOVE.L (SP+s15),C4; MOVE.L (SP+s15),De.E; MOVE.L (SP+s15),Do.E;
Size: 16
Signedness: Signed
Alignment: 0
Shift: 0
Overflow: Verify
Encoding: - - - - - - - - sss- - - - - - - - sssssssssssss
111 1119876543210
543 210
Special: The linker may provide an option to change the overflow type to type Verify. .
Applies to: ADDA #s16,rx,Rn; ADDNC.W#s16,Da,Dn; CMPEQ.W#s16,Dn; CMPGT.W#s16,Dn; IMPY.W#s16,Dn;
MAC#s16,Da,Dn; OVE.F #s16,Db; MOVE.W#s16,C4; MOVE.W#s16,(SP-u5); MOVE.W#s16,(Rn);
SUBNC.W#s16,Dn
Relocation
Size: 16
Signedness: Signed
Alignment: 1
Shift: 0
Overflow: Verify
Encoding: - - - - - - - - sss- - - - - - - - sssssssssssss
111 1119876543210
543 210
Applies to: AND.W#u16,(SP+s16); BMCHG.W#u16,(SP+s16); BMCLR.W#u16,(SP+s16);
BMSET.W#u16,(SP+s16); BMTSTC.W#u16,(SP+s16); BMTSET.W#u16,(SP+s16);
BMTSTS.W#u16,(SP+s16); EOR.W#u16,(SP+s16); MOVE.W#s16,(SP+sa16); NOT.W(SP+s16);
OR.W#u16,(SP+s16)
Type: 14, R_STARCORE_T16_0_0 (16-bit signed)
Size: 16
Signedness: Signed
Alignment: 0
Shift: 0
Overflow: Truncate
Encoding: - - - - - - - - - - - ss- - - - - - - - - - - - - - - - - - - - - ssssssssssssss
11 11119876543210
54 3210
Applies to: MOVE.W#s16,(a16); MOVE.W#s16,(SP+sa16)
Size: 32
Signedness: Signed
Alignment: 0
Shift: 0
Overflow: Truncate
Encoding: - - - - - - - - sssSS- - - - - - sssssssssssss - - SSSSSSSSSSSSSS
11133 1119876543210 22222222221111
54310 210 98765432109876
Applies to: MOVE.L #s32,C4
Relocation
Type: 16, R_STARCORE_U4_1_1 (4-bit unsigned)
Size: 4
Signedness: Unsigned
Alignment: 1
Shift: 1
Overflow: Verify
Encoding: - - - - - - - - - - - - - uuu
321
Applies to: MOVE.WDR,(Rn+u3); MOVE.W(Rn+u3),DR
Size: 5
Alignment: 2
Shift: 2
Overflow: Verify
Encoding: - - - - - - - - - - - - - uuu
432
Applies to: MOVE.L DR,(Rn+u3); MOVE.L (Rn+u3),DR
Size: 5
Alignment: 0
Shift: 0
Overflow: Verify
Encoding: - - - - - - - - - - - uuuuu
43210
Applies to: ADD#u5,Dn; ADDA #u5,Rx; ASLL #u5,Dn; ASRR #u5,Dn; CMPEQ.W#u5,Dn; CMPGT.W#u5,Dn;
LSRR #u5,Dn; SUB#u5,Dn; SUBA #u5,Rx
Size: 6
Alignment: 1
Shift: 1
Overflow: Verify
Encoding: - - - - - - - - - - - uuuuu
54321
Applies to: AND.W#u16,(SP-u5); BMCHG.W#u16,(SP-u5); BMCLR.W#u16,(SP-u5); BMSET.W#u16,(SP-u5);
BMTSET.W#u16,(SP-u5); BMTSTC.W#u16,(SP-u5); BMTSTS.W#u16,(SP-u5); EOR.W#u16,(SP-u5);
MOVE.W#s16,(SP-u5); NOT.W(SP-u5); OR.W#u16,(SP-u5)
Relocation
Size: 6
Alignment: 0
Shift: 0
Overflow: Verify
Encoding: - - - - - - - - - - uuuuuu
543210
Applies to: DOENn #u6; DOENSHn #u6
Size: 7
Alignment: 1
Shift: 1
Overflow: Verify
Encoding: - - - - - - - - - - uuuuuu
654321
Applies to: MOVE.WDR,(SP-u6); MOVE.W(SP-u6),DR
Size: 8
Alignment: 2
Shift: 2
Overflow: Verify
Encoding: - - - - - - - - - - uuuuuu
765432
Applies to: MOVE.L DR,(SP-u6); MOVE.L (SP-u6),DR
Type: 23, R_STARCORE_V6_0_0 (6-bit unsigned)
Size: 6 (range 0..39)
Alignment: 0
Shift: 0
Overflow: Verify
Encoding: - - - - - - - - - - - - - - - - - - - - uuuuuu- - - - - -
543210
Applies to: EXTRACT #U6,#u6,Db,Dn; EXTRACTU #U6,#u6,Db,Dn; INSERT #U6,#u6,Db,Dn
Relocation
Type: 24, R_STARCORE_W6_0_0 (6-bit unsigned)
Size: 6 (range 0..39)
Alignment: 0
Shift: 0
Overflow: Verify
Encoding: - - - - - - - - - - - - - - - - - - - - - - - - - - uuuuuu
543210
Applies to: EXTRACT #U6,#u6,Db,Dn; EXTRACTU #U6,#u6,Db,Dn; INSERT #U6,#u6,Db,Dn
Size: 16
Alignment: 0
Shift: 0
Overflow: Verify
Encoding: - - - - - - - - uuu- - - - - - - - uuuuuuuuuuuuu
111 1119876543210
543 210
Applies to: AND#0{u16},Da,Dn; BMCHG#u16,C1.L; BMCHG#u16,C1.H; BMCHG#u16,DR.L;
BMCHG#u16,DR.H; BMCHG.W#u16,(Rn); BMCHG.W#u16,(SP-u5); BMCLR #u16,C1.L;
BMCLR #u16,C1.H; BMCLR #u16,DR.L; BMCLR #u16,DR.H; BMCLR.W#u16,(Rn);
BMCLR.W#u16,(SP-u5); BMSET #u16,C1.L; BMSET #u16,C1.H; BMSET #u16,DR.L;
BMSET #u16,DR.H; BMSET.W#u16,(Rn); BMSET.W#u16,(SP-u5); BMTSET #u16,DR.L;
BMTSET #u16,DR.H; BMTSET.W#u16,(Rn); BMTSET.W#u16,(SP-u5); BMTSTC#u16,DR.L;
BMTSTC#u16,DR.H; BMTSTC#u16,C1.L; BMTSTC#u16,C1.H; BMTSTC.W#u16,(Rn);
BMTSTC.W#u16,(SP-u5); BMTSTS #u16,C1.L; BMTSTS #u16,C1.H; BMTSTS #u16,DR.L;
BMTSTS #u16,DR.H; BMTSTS.W#u16,(Rn); BMTSTS.W#u16,(SP-u5); DOENn #u16;
DOENSHn #u16; MOVE.BDR,(a16); MOVE.B(a16),DR; MOVEU.B(a16),DR
Size: 16
Alignment: 1
Shift: 0
Overflow: Verify
111 1119876543210
543 210
Applies to: AND.W#u16,(a16); BMCHG.W#u16,(a16); BMCLR.W#u16,(a16); BMSET.W#u16,(a16);
BMTSET.W#u16,(a16); BMTSTC.W#u16,(a16); BMTSTS.W#u16,(a16); EOR.W#u16,(a16);
MOVE.F (a16),Db; MOVE.WC4,(a16); MOVE.W(a16),C4; MOVE.W#s16,(a16); MOVES.F Db,(a16);
MOVEU.W(a16),C4; NOT.W(a16); OR.W#u16,(a16)
Relocation
Size: 16
Alignment: 2
Shift: 0
Overflow: Verify
111 1119876543210
543 210
Applies to: MOVE.L C4,(a16); MOVE.L (a16),C4
Type: 28, R_STARCORE_V16_0_0 (16-bit unsigned)
Size: 16
Alignment: 0
Shift: 0
Overflow: Truncate
Encoding: - - - - - - - - - - - uu- - - - - - - - - - - - - - - - - - - - - uuuuuuuuuuuuuu
11 11119876543210
54 3210
Applies to: BMCHG.W#u16,(a16); BMCHG.W#u16,(SP+s16); BMCLR.W#u16,(a16); BMCLR.W#u16,(SP+s16);
BMSET.W#u16,(a16); BMSET.W#u16,(SP+s16); BMTSET.W#u16,(a16); BMTSET.W#u16,(SP+s16);
BMTSTC.W#u16,(a16); BMTSTC.W#u16,(SP+s16); BMTSTS.W#u16,(a16);
BMTSTS.W#u16,(SP+s16)
Type: 29, R_STARCORE_N16_0_0 (16-bit unsigned)
Size: 16
Alignment: 0
Shift: 0
Overflow: Truncate
111 1119876543210
543 210
Special: The relocation value is exclusive-ORed with FFFFh.
Applies to: AND#u16,DR.L; AND#u16,DR.H; AND.W#u16,(Rn); AND.W#u16,(SP-u5)
Relocation
Type: 30, R_STARCORE_O16_0_0 (16-bit unsigned)
Size: 16
Alignment: 0
Shift: 0
Overflow: Truncate
11 11119876543210
54 3210
Special: The relocation value is exclusive-ORed with FFFFh.
Applies to: AND.W#u16,(a16); AND.W#u16,(SP+s16)
Size: 32
Alignment: 0
Shift: 0
Overflow: Truncate
Encoding: - - - - - - - - uuuUU- - - - - - uuuuuuuuuuuuu - - UUUUUUUUUUUUUU
11133 1119876543210 22222222221111
54310 210 98765432109876
Applies to: MOVE.L #u32,C1; MOVEU.L #u32,Db
Size: 32
Alignment: 1
Shift: 0
Overflow: Truncate
11133 1119876543210 22222222221111
54310 210 98765432109876
Special: The relocation value is truncated to 32 bits, without any range checking. No error/warning messages
are issued on truncation.
Applies to: J F label; J FDlabel; J MP label; J MPDlabel; J SR label; J SRDlabel; J T label; J TDlabel;
MOVE.F (a32),Db; MOVE.WDR,(a32); MOVE.W(a32),DR; MOVES.F Db,(a32); MOVEU.W(a32),DR;
Relocation
Size: 32
Alignment: 2
Shift: 0
Overflow: Truncate
11133 1119876543210 22222222221111
54310 210 98765432109876
Applies to: MOVE.L Da.E:Db.E,(a32); MOVE.L DR,(a32); MOVE.L (a32),DR; MOVE.L (a32),De.E;
MOVE.L (a32),Do.E
Size: 32
Alignment: 16
Shift: 16
Overflow: Truncate
332 2222222221111
109 8765432109876
Applies to: AND#{u16}$0000,Da,Dn
Type: 35, R_STARCORE_U16_0_0_TR (16-bit unsigned)
Size: 16
Alignment: 0
Shift: 0
Overflow: Truncate
111 1119876543210
543 210
Applies to: OR.W#u16,(SP-u5); EOR.W#u16,(SP-u5); OR #u16,DR.L; OR #u16,DR.H; EOR #u16,DR.L;
EOR #u16,DR.H; OR.W#u16,(Rn); EOR.W#u16,(Rn); MOVEU.W#u16,Db.L;
MOVEU.W#u16,Db.H;MOVEU.W#u16,Rn
Relocation
Type: 36, R_STARCORE_U32_0_0_AA (32-bit unsigned)
Size: 32
Alignment: 0
Shift: 0
Overflow: Truncate
11133 1119876543210 22222222221111
54310 210 98765432109876
Applies to: MOVE.B DR,(a32); MOVEU.B (a32),DR
Type: 37, R_STARCORE_V16_0_0_TR (16-bit unsigned)
Size: 16
Alignment: 0
Shift: 0
Overflow: Truncate
11 11119876543210
54 3210
Applies to: OR.W #u16,(a16); OR.W #u16,(SP+s16); EOR.W #u16,(a16); EOR.W #u16,(SP+s16)
Size: 4
Alignment: 0
Shift: 0
Overflow: Verify
Encoding: - - - - - - - - - - - - uuuu
3210
Special: This relocation type refers to SC3000-specific instructions.
Applies to: CLIP2 #u4,Dn; ASLL2 #u4,Dn; ASRR2 #u4,Dn; LSRR2 #u4,Dn
Relocation
Relocation stack For those situations in which the relocation value cannot be expressed as a simple symbol
value plus an addend, there are three special relocation types used to evaluate an arbitrary
expression on a relocation stack. These relocation types are referred to as extended
relocations. Other relocation types are ordinary relocations.
Type: 39, R_STARCORE_S16N_0_0 (16-bit signed)
Size: 16
Signedness: Signed
Alignment: 0
Shift: 0
Overflow: Truncate
Encoding: - - - - - - - - - uuu- - - - - - - uuuuuuuuuuuuu
111 1119876543210
435 210
Special: The linker may provide an option to change the overflow type to type Verify. This relocation type
refers to SC3000-specific instructions.
Applies to: MAC #s16, Da.L,Dn
Size: 20
Signedness: Signed
Alignment: 1
Shift: 4
Overflow: Verify
Encoding: - - - - - - - - sss- - SSS - - - sssssssss- - - S
111 111 111987654 1
543 987 210 6
Applies to: PFETCH label
Type: 41, R_STARCORE_U5N_0_0 (5-bit unsigned)
Size: 5
Alignment: 0
Shift: 0
Overflow: Verify
Encoding: - - - - - - - u- - - - uuuu
4 3210
Applies to: CMPEQA.W #u5,Rn; CMPGTA.W #u5,Rn
Relocation
A relocation stack is a standard last-in-first-out data structure containing 32-bit values. A
hosted environment must not place any arbitrary limit on the depth of the stack. An
embedded environment may impose any limit on stack depth or omit the relocation stack
entirely (effectively, a maximum stack depth of zero).
A relocation type of 252 (R_STARCORE_PUSH_PC) indicates that the sum of the symbol
value (the value of symbol number zero is zero) plus the signed r _addend value plus the
current location counter value should be pushed onto the relocation stack.
A relocation type of 253 (R_STARCORE_PUSH) indicates that the sum of the symbol value
(the value of symbol number zero is zero) plus the signed r _addend value should be
pushed onto the relocation stack.
Relocation
A relocation type of 254 (R_STARCORE_OPER) defines an operation to be performed on
one or more stack values. The operation is specified by the sum of the symbol value (the
value of symbol number zero is zero) plus the signed r _addend value. Operations are
shown in Table8. In the table, Stack0 indicates the value on the top of the stack, and
Stack1 indicates the value one level beneath the top of the stack.
Note that in most cases, the stack values are treated as unsigned. However, arithmetic
shifts and logical shifts are treated differently:
A relocation type of 255 (R_STARCORE_POP) indicates the end of a relocation expression,
to be relocated using an ordinary relocation type from Table7. The relocation type is
specified by the sum of the symbol value (the value of symbol number zero is zero) plus
the signed r _addend value.
Table 8. Relocation stack operations
Relocation
value
Before After Operation
Stack0 Stack1 Stack0
0 X X No operation
1 X -X Negation (2s complement)
2 X ~X Bitwise NOT (1s complement)
3 X !X Boolean NOT (zero -> 1, nonzero -> 0)
4 Y X X * Y Multiplication
5 Y X X / Y Division
6 Y X X % Y Remainder
7 Y X X + Y Addition
8 Y X X - Y Subtraction
9 Y X X <<< Y Logical shift left
10 Y X X >>> Y Logical shift right
11 Y X X << Y Arithmetic shift left
12 Y X X >> Y Arithmetic shift right
13 Y X X < Y 1 if X < Y, otherwise 0
14 Y X X <= Y 1 if X <= Y, otherwise 0
15 Y X X > Y 1 if X > Y, otherwise 0
16 Y X X >= Y 1 if X >= Y, otherwise 0
17 Y X X == Y 1 if X equals Y, otherwise 0
18 Y X X != Y 1 if X does not equal, otherwise 0
19 Y X X & Y Bitwise AND
20 Y X X | Y Bitwise XOR
21 Y X X ^ Y Bitwise OR
22 Y X X && Y 1 if X and Y both nonzero, otherwise 0
23 Y X X || Y 1 if X or Y or both nonzero, otherwise 0
Logical shift left: Zeroes are shifted in on the right.
Logical shift right: Zeroes are shifted in on the left.
Arithmetic shift left: Zeroes are shifted in on the right, and the most significant bit is
always unaffected.
Arithmetic shift right:Copies of the most significant bit are shifted in on the left.
Relocation
When the R_STARCORE_POP operation is encountered, there should be exactly one value
on the stack. This value, which is consumed by this operation, becomes the new relocation
value for the ordinary relocation type specified in the R_STARCORE_POP relocation.
It is the responsibility of the relocation engine to ensure that the stack is empty after an
R_STARCORE_POP, before an ordinary relocation, and after linking is complete. A
sequence of relocations which causes a stack underflow does not conform to the ABI.
Instruction address
vs. VLES address
Within a variable-length execution set (VLES), all instructions share a common value of
the PC register, specifically the starting address of the VLES itself. The r _of f set field
of a relocation points to the instruction address, not the VLES address. To compensate for
this, a PC-relative instruction must have the instruction offset subtracted from the PC-
relative operand as follows:
1. In an ordinary relocation, the offset should be subtracted from the value in the
r _addend field. Example:
The dosetup3 instruction would generate an ordinary relocation with the following
field values:
r _i nf o: ELF32_R_I NFO( <symbol number of l pt ab>, R_STARCORE_R17_1_1)
r _addend: 26 ( 32 - 6)
VLES offset Instruction
0 (1w prefix) [
2 t st eq d2
4 doen3 d4
6 doset up3 l pt ab+32
]
Relocation
2. In an extended relocation, the subtraction of the offset should be inserted at the end of
relocation expression, just before the R_STARCORE_POP operation. Example:
The dosetup3 instruction would generate a sequence of extended relocations with the
following field values:
The relocations marked with asterisks implement the offset subtraction.
VLES offset Instruction
0 (1w prefix) [
2 t st eq d2
4 doen3 d4
6 doset up3 l pt ab+4*ndx
]
r_info (type shown first, then symbol) r_addend
R_STARCORE_PUSH <symbol number of l pt ab> 0
R_STARCORE_PUSH 0 4
R_STARCORE_PUSH <symbol number of ndx> 0
R_STARCORE_OPER 0 4 ( *)
R_STARCORE_OPER 0 7 ( +)
* R_STARCORE_PUSH 0 6
* R_STARCORE_OPER 0 8 ( - )
R_STARCORE_POP 0 R_STARCORE_R17_1_1
NOTE Section
NOTE Section
The note section is optional. It contains object file vendor identification and application-
specific object file comments. If included, it follows the described format.
Vendor identification format is shown in Figure3. It consists of the following:
Figure 3. Vendor identification note format
Object file comments generated by the user through an assembler directive are placed in
the note section. This is typically for users to identify their object code. The same string
termination and padding restrictions apply to object file comments as apply to vendor
identification notes. The field contains a user-specified comment. A null comment ( \0 ) is
not a valid comment.
namesz
The string length (not counting null terminator) of the name. It is a 4-byte
unsigned integer.
descz
The size of the description entries. This is 12 bytes for the vendor id note. The
description fields contain the version, revision, minor revision numbers of the
producing entity (assembler or linker). Data is an unsigned 4-byte integer.
t ype
Type equals 2 for the vendor identification note. It is a 4-byte unsigned integer
in little-endian order.
name
Null terminated string and padded, if necessary, to achieve a 4-byte boundary
alignment which represents the vendors identification.
namesz
descsz
type
0 1 2 3
name v e n d
o r i d
2 (Vendor ID note)
\0 pad pad pad
Version number
Revision number
Bytes
Minor rev number
NOTE Section
The object file comment format is shown in Figure4.
Figure 4. User (application-specific) note format
namesz
descsz
type
1 2 3
name c o m m
e n
0
1
0
t \0
Program Headers
Program Headers
Program headers are used to build an executable image in memory and are only useful for
executable files. While section headers may or may not be included in executable files,
program headers are always present. See Example21 for a sample program header.
Example21. Program header
t ypedef st r uct {
El f 32_Wor d p_t ype;
El f 32_Of f p_of f set ;
El f 32_Addr p_vaddr ;
El f 32_Addr p_paddr ;
El f 32_Wor d p_f i l esz;
El f 32_Wor d p_memsz;
El f 32_Wor d p_f l ags;
El f 32_Wor d p_al i gn;
} El f 32_Phdr ;
The program header members are described below.
p_t ype
Describes the type of program header. Only PT_LOAD and PT_NOTE are
recognized as types.
p_of f set
Offset from beginning of file to first byte of segment.
p_vaddr
Virtual address in memory of the first byte of the segment.
p_paddr
Physical address in memory of the first byte of the segment.
p_f i l esz
Gives the number of bytes in segments file image. (May be zero.)
p_memsz
Gives the number of bytes in segments memory image. (May be zero.)
p_f l ags
Gives flags relevant to the segment. Defined flags are PF_R, PF_W, and
PF_X.
p_al i gn
Segment alignment requirements in file and memory.
Debugging Information
Debugging Information
Tools for the StarCore architecture must use the Debug With Arbitrary Record Format
(DWARF) debugging format, as defined in the Tool Interface Standard (TIS) DWARF
Debugging Information Format Specification, Version 2.0.
DWARF register
number mapping
Table9 outlines the register number mapping for the StarCore processor cores.
Table 9. StarCore register number mapping
Register name Number Abbreviation
Stack Pointer 0 SP
General Data Registers 116 D0D15
Address Registers 1732 R0R15
Data Registersextension portion 3348 D0_eD15_e
Data Registershigh portion 4964 D0_hD15_h
Data Registerslow portion 6580 D0_lD15_l
Loop Counter Registers 8184 LC0LC3
Modulo Registers 8588 M0M3
Offset Registers 8992 N0N3
Program Counter 93 PC
Clock Control Registers 9497 PCTL0PCTL3
Start Address Registers 98101 SA0SA3
Vector Base Address Register 102 VBA
Exception and Mode Register 103 EMR
Modifier Control Register 104 MCTL
Agere Systems Inc. reserves the right to make changes to the product(s) or information contained herein without notice. No liability is assumed as a result of their use or application.
Agere, Agere Systems, and the Agere logo are registered trademarks of Agere Systems Inc. StarPro is a trademark of Agere Systems Inc.
Copyright 2007 Agere Systems Inc.
All Rights Reserved
February 2007
(b7)
For additional information, contact your Agere Systems Account Manager or the following:
INTERNET: Home: http://www.agere.com Sales: http://www.agere.com/sales
E-MAIL: docmaster@agere.com
N. AMERICA: Agere Systems Inc., Lehigh Valley Central Campus, Room 10A-301C, 1110 American Parkway NE, Allentown, PA 18109-9138
1-800-372-2447, FAX 610-712-4106 (In CANADA: 1-800-553-2448, FAX 610-712-4106)
ASIA: CHINA: (86) 21-54614688 (Shanghai), (86) 755-25881122 (Shenzhen), (86) 10-65391101 (Beijing)
J APAN: (81) 3-5421-1600 (Tokyo), KOREA: (82) 2-767-1850 (Seoul), SINGAPORE: (65) 6741-9855, TAIWAN: (886) 2-2725-5858 (Taipei)
EUROPE: Tel. (44) 1344 865 900

ABI 4.0 Spec

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ABI 4.0 Spec

Hochgeladen von

Copyright:

Verfügbare Formate

Specification

Das könnte Ihnen auch gefallen