ABI_4.0_Spec

8/11/2019 ABI_4.0_Spec

http://slidepdf.com/reader/full/abi40spec 1/96

Specification

February 2007

StarCore ABI 4.0

Agere Systems - Proprietary

IntroductionThis document is a reference for the StarCore™Application Binary Interface (ABI) for the followingfamilies of StarCore™ processor cores (and earliercores):

SC1000

SC2000

SC3000

The ABI definition ensures interoperability betweendifferent tools, like compiler, assembler, linker anddebugger on object code level.

This document is intended for tool developers aswell as for low level assembly programmers.

To summarize , this document will discuss thefollowing topics:

The low level binary interface. It contains adefinition of all basic data types and the functioncalling conventions.

The high level language issues. It describes theC++ ABI and the runtime functions of thelibrary.

The object file format. It describes the StarCoreextensions to the ELF object file format.

8/11/2019 ABI_4.0_Spec


8/11/2019 ABI_4.0_Spec


Specification

February 2007 Contents

Agere Systems - Proprietary 3

Contents

Preface About This Document 13

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

What’s covered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Source Level Compatibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

What’s 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Stack 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

8/11/2019 ABI_4.0_Spec


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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Loop 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

8/11/2019 ABI_4.0_Spec


8/11/2019 ABI_4.0_Spec


Specification

Contents February 2007


8/11/2019 ABI_4.0_Spec


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

8/11/2019 ABI_4.0_Spec


Specification

Tables February 2007


8/11/2019 ABI_4.0_Spec


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

8/11/2019 ABI_4.0_Spec


Specification

Figures February 2007


8/11/2019 ABI_4.0_Spec


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

8/11/2019 ABI_4.0_Spec


Specification

Examples February 2007


8/11/2019 ABI_4.0_Spec


8/11/2019 ABI_4.0_Spec


Preface Specification

About This Document February 2007

Overview


The ABI conformance is defined on public visible interfaces (e.g. external visiblefunctions or variables) of an object file. But a compiler implementation is free to makedeviations 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 intoaccount. So the caller function may use free hardware loop resources or avoidsaving of untouched scratch registers. For static functions, the compiler mayeven 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 compilerimplementation how such deviations are compatible to the standard ABI.

For example a compiler may provide a command line option to specify adifferent default setting for mode bits. In this case all object files must becompiled 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 LevelCompatibility

Source level compatibility on C or assembly source level is not defined in the ABI. But itis recommended that compiler and assembler implementations follow the source levelconventions as described in the StarCore compiler and assembler manuals. These include

Assembly syntax

Compiler intrinsics

Pragmas

C/C++ language extentions

Inline assembly

8/11/2019 ABI_4.0_Spec


Specification Preface

February 2007 About This Document

What’s New in StarCore ABI 4.0


What’s New in StarCore ABI 4.0

StarCore ABI 4.0 supersedes the previous revision (3.0) and includes information thatapplies 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.

8/11/2019 ABI_4.0_Spec




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 ReviewDraft, UNIX International, Program Languages SIG, July 27, 1993

ANSI/IEEE Std 754-1985, IEEE standard for binary floating-point arithmetic datatypes

ISO/IEC 9899:1999(E), International Standard - Programming Languages—C , 2ndEdition, International Organization for Standardization, December 1, 1999

ISO/IEC 14882:2003(E), International Standard - Programming Languages—C , 2ndEdition, 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 theSC1200 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.

8/11/2019 ABI_4.0_Spec


Specification Preface

February 2007 About This Document

Conventions


Conventions

Introduction This document uses certain conventions to assist you in identifying, locating, andunderstanding 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

8/11/2019 ABI_4.0_Spec




Acknowledgements


Acknowledgements

The StarCore Application Binary Interface team included representatives from thefollowing companies:

We gratefully thank all participants for devoting their time and effort to create thisstandard.

Agere Systems Inc. Metrowerks, Inc.Altium Limited Motorola, Inc.

Green Hills Software, Inc. WindRiver Systems, Inc.

Lineo, Inc.

8/11/2019 ABI_4.0_Spec



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 offundamental data types)

Function calling conventions (how arguments are passed and results are returned, howregisters are assigned, and how the calling stack is organized)

StarCore Architectures

The StarCore processor core architectures currently includes six cores: the SC1200, theSC1400P, the SC2200, the SC2400 , the SC3200, and the SC3400. The architecture andinstruction set for each core is defined in that core’s respective reference manual, as listedin “Additional Resources” on page 16. Programs written for these cores use theirinstruction sets, as well as the instruction encodings and semantics of their architecture.Programmers may assume that the instructions for these cores work as documented. Notethat all cores are backwards compatible to their respective predecessor, but while anABI-conforming SC1200 program will run on an ABI-conforming SC1400 processor, thereverse is not always true.

To conform to the ABI, the processor must execute the architecture’s 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 beimplemented in hardware. A software emulation of the architecture could conform to theABI.

Programs that use non-StarCore instructions or capabilities do not conform to the StarCoreABI. Such programs may produce unexpected results when run on machines lacking thenon-StarCore capability.

8/11/2019 ABI_4.0_Spec


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 viceversa. The same applies to the data generated by these programs, as well as to the layout ofdata 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 thefollowing:

In a big-endian implementation, the most significant byte (MSB) is located in thelowest address (byte 0).

In a little-endian implementation, the least significant byte (LSB) is located in thelowest address (byte 0).

8/11/2019 ABI_4.0_Spec


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 ormemory. Data stored in registers are always little-endian mapped, whereas data inmemory are mapped according to the current endian mode.

Example 1. Word bit and byte numberingRegister mapping

Memory mapping

Example 2. Long word bit and byte numberingRegister mapping

Memory mapping

bit 15 8 7 0

byte 1MSB LSB

byte 0Little-Endian

bit 15 8 7 0

byte 1MSB LSB

byte 0Big-Endian

bit 15 8 7 0

byte 1MSB LSB

byte 0Little-Endian

bit 15 8 7 0

byte 0 MSB LSB byte 1 Big-Endian

bit 31 24 23 16 15 8 7 0

byte 3MSB LSB

byte 0Little-Endian

bit 31 24 23 16 15 8 7 0

byte 3MSB LSB

byte 0Big-Endian

bit 31 24 23 16 15 8 7 0

byte 3MSB LSB

byte 0Little-Endian

bit 31 24 23 16 15 8 7 0

byte 0MSB LSB

byte 3Big-Endian

8/11/2019 ABI_4.0_Spec






Example 3. Double-long word bit and byte numberingRegister mapping

Memory mapping

Note Support for 64-bit data is optional and an implementation may not accept the “longlong” C type.

bit 31 24 23 16 15 8 7 0

Little-Endian byte 3

LSBbyte 0

bit 63 56 55 48 47 40 39 32

byte 7MSB

byte 4

bit 31 24 23 16 15 8 7 0


LSBbyte 0

bit 63 56 55 48 47 40 39 32

byte 7MSB

byte 4

bit 31 24 23 16 15 8 7 0


LSBbyte 0

bit 63 56 55 48 47 40 39 32

byte 7MSB

byte 4

bit 63 56 55 48 47 40 39 32

Big-Endian

byte 0MSB

byte 3

bit 31 24 23 16 15 8 7 0

byte 4LSB

byte 7

8/11/2019 ABI_4.0_Spec






Table 1 shows the mapping between these fundamental data types and the C language datatypes. Note that fundamental data is always naturally aligned; that is, a double-long wordis 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 –27 through 27 – 1 Signed byte

si gned char

unsi gned char 8 8 0 through 28 – 1 Unsigned byte

short 16 16 –215 through 215 – 1 Signed word

si gned shor t

unsi gned short 16 16 0 through 216 – 1 Unsigned word

Integral i nt 32 32 –231 through 231 – 1 Signed long word

si gned i nt

enum

l ong

si gned l ong

unsi gned i nt 32 32 0 through 232 – 1 Unsigned long word

unsi gned l ong

l ong l ong1 64 64 –263 through 263 – 1 Signed double-long

wordsi gned l ong l ong1

unsi gned l ong l ong1 64 64 0 through 264 – 1 Unsigned double-

long word

Pointer poi nt er t o dat a 32 32 0 through 232 – 1 Unsigned long word

poi nt er t o f uncti on

Floating-

point2f l oat 32 32 –3.402e38 through –1.175e –38

1.175e –38 through 3.402e38

Unsigned long word

doubl e3 32 or

64

32 or 64 2.225e –308 through 1.797e308

or 1.175e –38 through 3.402e38Unsigned double-

long wordl ong doubl e3

1This 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.

2Floating-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 .

8/11/2019 ABI_4.0_Spec






Fractional types are supported in C using intrinsic functions; Table 2 shows the fractionaltypes 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 short 16 16 –1 through

Long fractional l ongi 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.

215

1 – ( )

215

----------------------

231

1 – ( )

231

----------------------

239

1 – ( )

231

----------------------

263

1 – ( )

263

----------------------

8/11/2019 ABI_4.0_Spec




Aggregates and Unions



The alignment of aggregates (structures and unions) is the maximum of the followingvalues:

The alignment of their most strictly aligned member (that is, the member with thelargest alignment).

A minimum alignment of 4.

An implementation may provide a user option that overrides the minimum structurealignment. In particular, if the user may select a minimum alignment of 0 or 1, theaggregate alignment is simply the largest alignment of its members.

Modules compiled with different minimum alignments cannot interoperate if theyinterface using structures or unions.

For example, a structure containing a char , a short , and an i nt must have a 4-bytealignment 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 alignedmember.

Each member is allocated starting at the next byte that satisfies the alignmentrequirement for that member. This may require internal padding.

If necessary, a structure’s size is increased to make it a multiple of the structure’salignment. 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. InExample 4, there is internal padding so that the first short (s1) starts at a word boundary.Tail padding makes the structure size a multiple of the i nt member’s 4-byte alignment.

8/11/2019 ABI_4.0_Spec






Example 4. Structure with internal and tail paddingst r uct { / * 12 bytes, 4- byte al i gned */ char c; short s1; i nt i ; short s2;

};

Example 5. Union allocationuni on { / * 4 bytes, 4- byte 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 11pad 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


pad sbyte 0

pad c

l

bit 31 24 23 16 15 0

Big-Endian byte 0

s padbyte 3

c pad

l

8/11/2019 ABI_4.0_Spec




Bit Fields


Bit Fields

Structure and union definitions may have bit fields as listed in Table 3.

Support of _Bool is optional, but all other types shown in Table 3 must be supported. ThisABI does not have requirements for l ong l ong bit fields.

Unsigned bit-field values range from 0 to 2w−1, where w is the bit field’s width in bits.Signed bit-field values range from –2w−1 to 2w−1 – 1.

Table 3. C bit field typesC 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 short 2

1 to 16

i nt

si gned i ntenum2

l ong2

si gned l ong2

unsi gned i nt

unsi gned l ong2

1 to 32

1Support of _Bool is optional. If implemented, it must be implemented with the width and range shown.2This bit field type is not required for ISO C conformance, but is required for ABI conformance.

8/11/2019 ABI_4.0_Spec




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 negativevalues), bit fields of these types have the same range as bit fields of the same size with thecorresponding signed type. The same size and alignment rules that apply to other structureand 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 fieldoccupies 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 fieldoccupies 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 fieldcannot 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 field’s member offsets obey the alignment constraints. Anunnamed, zero-width bit field prevents any further member (either bit field or non-bitfield) from residing in the storage unit corresponding to the type of the zero-width bitfield.

Note in the following examples that alignments are driven not by the widths of the bitfields but by the underlying types. Example 6 shows a structure that is 4-byte aligned andhas 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.

Example 6. Bit field alignment and paddingst r uct { / * 4 bytes, 4- byte al i gned */ 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 0Little-Endian

↑ pad

bit 31 28 25 24 23 19 18 16 15 0

byte 0 a b c pad d

byte 3Big-Endian

↑ pad

8/11/2019 ABI_4.0_Spec




Bit Fields


In Example 7, the structure is at least 2-byte aligned because the unnamed l ong bit fielddoes 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 page 25.) The zero-width short bit field pads to the next word boundary.

Example 7. Unnamed and zero-width bit fieldsst r uct { / * 8 bytes, 2- byte al i gned */ short a : 9; shor t : 0; char b : 5; l ong : 15;};

bit 31 21 20 16 15 9 8 0


pad b pad abyte 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 padbyte 3

bit 31 0

byte 4pad

byte 7

8/11/2019 ABI_4.0_Spec




Argument Passing and Register Usage



This section describes the argument passing and register usage of the ABI version 4. Itdiffers 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 R0to R3, according to the following rules:

If a function argument is of integral, floating point, or structure type, and its size is lessthan or equal to 32 bits, the argument is passed in a data register (D0 to D3). Allregister bits exceeding the arguments size are defined by the sign of the correspondingtype. For example, an argument of type shor t is passed in bits 15–0 and bits 39–16 areequal 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 64 bits 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 dataregister pair (either D0 and D1, or D2 and D3).The data register with the lower numbercontains the most significant 32 bits (sign or zero extended to 40 bits, according to thetype), the other one contains the least significant 32 bits (zero extended to 40 bits),regardless of the byte order.

If a function argument is of structure type, and its size is larger than 32 bits and less orequal to 64 bits, it is passed in a data register pair (either D0 and D1, or D2 andD3).The data register with the lower number contains the most significant 32 bits, theother one contains the least significant 32 bits.

The register arguments are allocated while working off the argument list from left toright. Whenever an argument fulfills one of the previously mentioned data type criteriaand a register (or register pair) out of the corresponding register list is still available, itis assigned.

All arguments that are not passed via registers are passed on the stack. Stack argumentsadhere the rules of the previously specified standard calling convention.

Variable argument passing is handled as previously specified.

8/11/2019 ABI_4.0_Spec






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 thanor equal to 32 bits, the return value is passed in D0. All register bits exceeding thereturn values type size are defined by the sign of the corresponding type. For example,an argument of type short is passed in bits 15–0 and bits 39–16 are equal to the valueof bit 15 (the sign bit).

If an implementation supports 64 bits 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 thedata register pair D0 and D1. D0 contains the most significant 32 bits (sign or zeroextended to 40 bits, according to the type), D1contains the least significant 32 bits(zero extended to 40 bits), regardless of the byte order.

If the return value is of structure type, and its size is larger than 32 bits and less or equalto 64 bits, it is passed in D0 and D1. D0 contains the most significant bits, D1 containsthe least significant 32 bits.

If the return value is of pointer type, it is passed in R0.

A struct or uni on larger than 64 bits causes the compiler to allocate stack space forthe data structure on the caller's stack frame. The called function obtains a pointer tothe stack location in register R0 as a hidden function parameter. Hence the list ofavailable 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 andRestoring Functions

The compiler may use runtime function calls instead of PUSH and POP instructions forregister saving and restoring to reduce code size. These functions are described in“Register saving and restoring functions” on page 57.

Example 8. 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 firstargument (sc) in D0, and the second argument (l l ) in the register pair D2 and D3. Finallythe last argument (us) is passed in D1, as this is the last available data register. Bits 39–8of D0 are set to bit 7 (sign bit). Bits 39–32 of D2 are set to zero and bits 39–32 of D3 areset to bit 31 (sign bit). The last argument is unsigned, hence bits 39–16 of D1 are set tozero. The caller expects the return value in the least significant 8 bits of D0. Bits 39–8 ofD0 are equal to the sign bit (bit 7).

Function Call 2:str uct poi nt r ot at e (Word40 x, i nt *i , char *f or mat , . . . ) ;

8/11/2019 ABI_4.0_Spec






When the rotate function is called in the source code, the compiler passes the firstfunction 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 (structpoi 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.

8/11/2019 ABI_4.0_Spec






Table 4 summarizes register usage in the ABI 4 calling convention.

ABI indicators To avoid an accidentally mismatch of calling conventions, the linker checks if the callingconventions of caller and callee functions match. The compiler generates specialindication-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 symbolis named __abi 4. _f oo. These symbols are generated for functions, which are defined ina module and functions, which are referenced from a module.

With this information the linker prints an error if an ABI4 function calls an ABI2 functionor vice versa. Note that this error checking is not done if a function is called over afunction 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

D4–D7 +

D8–D15 +

D0.e–D3.e +

D3.e–D7.e + The extension bits are either not modified by the callee or sign extended,

i.e. bits 31 to 39 are equal.

D8.e–D15.e +

R0 + First pointer argumentReturn pointer value

Structure or union return address

R1-R3 + Second to fourth pointer argument

R4-R7 +

R8–R15, B0–B7 +

N0–N3, M0–M3 +

SP (NSP, ESP) +

8/11/2019 ABI_4.0_Spec




Argument Passing and Register Usage of ABI Version 2



This section describes the argument passing and register usage of the ABI version 2. Thisversion of the calling convention is only provided for backward compatibility. An

implementation should prefer the ABI version 4 calling convention. An implementationmay 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 isa 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 ongdoubl e, it is passed in D0 and D1, D0 containing the most significant long word andD1 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 andD1 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 onthe stack.

When an argument is passed in D0 or D1, all the register bytes that are part of theargument are defined by extension to the corresponding type. For example, a firstargument of type short is passed in D0[15:0], and the contents of D0[31:16] and D0.econtain 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 forlong long and long double, zero-extending the 32 most significant bits for unsignedlong long.

All other arguments are passed on the stack. Note that the first argument may be passedon 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 page 21, “Aggregates and Unions” on page 25, and “Bit Fields” on page 27 is passed8-byte aligned on the stack. All other arguments are passed using their alignmentconstrains. For example, a short type is 2-byte aligned.

The constituent bytes of an integral argument of fewer than 4 bytes are located on thestack using their original size and constrains.

The alignment of aggregates on the stack is at least 4 bytes, even if the compileroptionally supports an aggregate alignment of less than 4 bytes.

8/11/2019 ABI_4.0_Spec






Variable ArgumentPassing

ANSI C requires that before a function with a variable argument list is called, it must bedeclared with a prototype containing a trailing ellipsis (. . . ). Following rules apply tofunctions with variable arguments.

Functions with a variable number of arguments pass the last fixed argument and allsubsequent variable arguments on the stack. Such arguments of fewer than 4 bytes arelocated on the stack as if the argument had been promoted to 32 bits. The rules aboveapply to arguments before the last fixed argument.

Variable arguments, which have a size of 8 bytes or more, are passed 8-bytes alignedon the stack.

If the compiler supports aggregates with an alignment of less than 4 bytes thenfollowing rule applies for variable arguments in big endian: The padding bytes ofaggregates with a size, which is not a multiple of 4 bytes, are inserted before theaggregate. 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 bitsand returned in D0. A float value is returned in D0, sign-extended to 40 bits. A l ongl ong, doubl e, or l ong doubl e return value is returned in D0 and D1, D0 containingthe 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-extendedto 40 bits for returned values of type long double and long long, and it is zero-extendedto 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 preservedor 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 page 57.

8/11/2019 ABI_4.0_Spec






Example 9 shows two function calls and the arguments that are allocated for each call.

Example 9. Function calls and allocation of arguments

Function Call 1:

f oo( i nt a1, st r uct f our bytes a2, st r uct ei ght byt es a3, shor t a4)

Arguments:

a1 - i n r egi st er d0a2 - on the st ack at SP - 4 ( SP = st ack poi nt er addr ess)a3 - on t he stack at SP - 12a4 - on t he stack at SP - 14

Function Call 2:

bar ( l ong *b1, i nt b2, char b3, i nt b4[ ] )

Arguments:

b1 - i n r 0b2 - i n d1b3 - on stack at SP - 4b4 – on stack at SP - 8

8/11/2019 ABI_4.0_Spec






Table 5 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

D2–D5 +

D6–D7 +

D8–D15 +

D0.e–D5.e +

D6.e–D7.e + The extension bits are either not modified by the callee or sign extended,

i.e. bits 31 to 39 are equal.

D8.e–D15.e +

R0 + First pointer argument

Return pointer value

R1 + Second pointer argument

R2 + Structure or union return address

R3–R5 +

R6-R7 +

R8–R15, B0–B7 +

N0–N3, M0–M3 +

SP (NSP, ESP) +

8/11/2019 ABI_4.0_Spec




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 beimplemented as “(sp)+”). Initially a long word with value –1 is pushed at offset 0 on thestack to serve as a top-of-stack marker. The stack pointer must be 8-byte aligned.

Frame and globalpointers

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 mayallocate R7 as a frame pointer and R6 as a global pointer. When these registers areallocated 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 higheraddresses than the stack pointer is considered invalid and may actually be unaddressable.The stack pointer value must always be a multiple of eight.

Figure 1 shows typical stack frames for a function and indicates the relative position oflocal variables, arguments, and return addresses. The stack grows upward from lowaddresses.

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 argumentsarea. If all arguments fit in registers, this area is not required. A caller may allocateoutgoing 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 localvariables 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. Thisreturn buffer area is typically located with the local variables, but it may be the address ofa global variable. This space is typically allocated only in functions that make callsreturning structures.

A “return address” value of FFFFFFFFh (–1) is used to denote the current frame as theoutermost (oldest) frame on the current call stack. This convention requires that theoutermost frame be manually constructed and that sufficient object file details areavailable 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 waydesired.

8/11/2019 ABI_4.0_Spec




Stack


Figure 1. Stack frame layout

Stack unwinding The compiler will create special symbols when a module is compiled without debugenabled (for example., the - g compiler option is not used). These symbols will appear aslocal symbols in the . symt ab ELF section and will have the following syntax:

TextStar t _<modul e_name> : modul e’ s l ow PC TextEnd_<modul e_name> : modul e’ s hi gh PCSt ackOf f set _<l abel > : si ze of st ack at l abelFuncEnd_<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 thesame conventions as assembly language labels. These conventions are outlined in“Symbol names” on page 103.

<label> is a program label within the function. The value of StackOf f set _ label isthe size of the stack frame at the label. The size is in 4-byte words and does not includean implied JSR/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

andsaved registers

http://abi_4.0_spec_assembler.pdf/

http://abi_4.0_spec_assembler.pdf/

8/11/2019 ABI_4.0_Spec




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, thetype NOTYPE means a symbol type of STT_NOTYPE, and the section ABS means a symboltable entry of SHN_ABS.

Example 10 illustrates how these symbols might be defined in an assembly-language program.

Example 10. Generating stack unwinding symbols in assembly codesecti on . t ext l ocal

TextStar t _hel l o

; **************************************************************; Exampl e f unct i on _mai n; **************************************************************

gl obal _mai n _mai n t ype f unc [ push r6 push r 7 ]DW_2. . . [ pop r 6 pop r 7 ]DW_5r t s

FuncEnd__mai n

StackOf f set __mai n equ 0 ; At _mai n sp = 0 wordsStackOf f set _DW_2 equ 2 ; At DW_2 sp = 2 wordsStackOf f set _DW_5 equ 0 ; At DW_5 sp = 0 words

TextEnd_hel l oendsec

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 StackOf f set __mai n2h 0 LOCAL NOTYPE ABS StackOf f set _DW_2

0h 0 LOCAL NOTYPE ABS StackOf 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

8/11/2019 ABI_4.0_Spec




Configuration Registers



Field Types There are several types of fields in the configuration registers.

Field with defined stateSuch a field has a defined value at function entry and function exit. The compiler is free tochange 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 afield. But then no compatibility exists to modules, which are compiled with the defaultstate.

Destroyed field

A destroyed field has no defined value at function entry and exit, but the compiler is freeto 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 doesn’t need to berestored 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 fieldautomatically. 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 notset 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 hardwareloops.

I, OVE, DI, EXP, PE

These fields are under user control.

VF3-VF0

These fields may be destroyed by a function.

SM2The 16-bit arithmetic saturation mode must be enabled on function entry and exit, i.e. theSM2 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.

8/11/2019 ABI_4.0_Spec






RM

The rounding mode must be set to to twos-complement rounding on function entry andexit, 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. theSM bit must be 1b.

It is recommended that a compiler implementation provides an option so that no saturationis assumed.

T, C

The true and carry bits are status bit and don’t have a defined value on function entry andexit.

Exception and Mode

Register (EMR)

All fields in the EMR register are status bits or under user control. Therefore they don’t

have a defined value at function entry and exit.

GeneralConfigurationRegister (GCR)

BAM[2]

The bit 2 of the BAM field indicates the shift direction of the DOALIGN instruction. Inlittle 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 don’t have adefined 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 addresscalculation methods for R0–R7 as linear.

Hardware loops From the definition of the loop fields in SR (SLF, LF3, LF2, LF1, LF0) follows that allhardware loop resources are available for the compiler’s use. As it is assumed that nonesting occurs when entering a function, a function may use all four nesting levels for itsown use.

8/11/2019 ABI_4.0_Spec




Static Programming Rules


Static Programming Rules

Overview The programming rules are described in the core reference manuals (CRM). Many ofthese 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 belongsto 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 JSR, BSR and RTS. This meansthat the ABI defines how the rules have to be checked around function calls and returns.

Enforce at COFSource

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 therules are not violated, regardless of what instruction is located at the COF target (at afunction 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 orwrites to EMR.

Loop Rules Rules, which affect the loop registers and loop modes are not part of the ABI, because thecode, which affects a loop may not be splitted across functions and there may not be afunction call inside a loop (except the compiler is under control of the called function).

8/11/2019 ABI_4.0_Spec




Memory Models


Memory Models

Overview A compiler implementation may provide several memory models for code and data togenerate more compact instructions for addressing. There are several ways to specify thememory model. For example, commnd line switches can specify the memory model for allentities in a compilation module. It is also possible that a compiler provides pragmas tospecify the memory model of separate functions or variables.

The memory models allow the compiler to generate references to global and static dataand function calls without global knowledge as to the variables’ or functions’ finalallocation address in memory. For each model, the compiler will assume that references toglobal 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 isresolved to not fit within the range defined by the memory model.

Object files, which are compiled with different memory models (or contain entities withdifferent 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 JSR instruction may be generated.

huge: There is no restriction on the distance between the function call and the functionentry. Therefore the compiler must generate a 32-bit absolute call.

Example 11. Code memory models; Smal l memor y modelbr s >_f unc ( 2 16-bi t words)

; Huge memor y model j sr _f unc ( 3 16- bi t words)

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 ofa 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. Thismemory model is optional

tiny for small variables: For non-array variables up to a size of 8 bytes, the tiny modelis used. For array variables and variables larger that 8 bytes, the default memory model(usually big memory) is used. This memory model is optional.

8/11/2019 ABI_4.0_Spec




Memory Models


Example 12. Data memory models; Smal l memor y modelmove. l <_var, d0 ( 2 16- bi t words)moveu. l #_var, d0 ( 3 16- bi t words)

; Bi g memor y model

move. l _var , d0 ( 3 16- bi t words)moveu. l #_var, d0 ( 3 16- bi t words)

; Ti ny memor y modelmove. l <_var, d0 ( 2 16- bi t words)move. w #_var , d0 ( 2 16- bi t words)

; Ti ny for smal l var i abl es memory model ( wi t h bi g memory as defaul t )move. l <_smal l var , d0 ( 2 16- bi t words)move. w #_smal l var, d0 ( 2 16- bi t words)move. l _l argevar , d0 ( 3 16- bi t words)moveu. l #_l argevar, d0 ( 3 16- bi t words)

8/11/2019 ABI_4.0_Spec




Memory Models


8/11/2019 ABI_4.0_Spec



Chapter 2 High-Level Language Issues

Name Mapping

C Name Mapping Externally visible names in the C language are prefixed by an underscore ( _ ) whengenerating 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: : memberf unc( char, l ong) const { . . .}

generates following assembly name:

__ ZNK5Cl ass10memberf uncEcl

8/11/2019 ABI_4.0_Spec



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 callwrappers. 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 rd arg i s mode_t i f pr esent .i nt c l ose( i nt) ;ssi ze_t r ead(i nt , voi d *, si ze_t) ;ssi ze_t wri 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 *) ;

8/11/2019 ABI_4.0_Spec



February 2007 High-Level Language Issues

Libraries


Libraries

The following sections provide details on support libraries.

Compiler assistlibraries

The StarCore architecture does not provide hardware support for floating-point data types,nor for divide functionality for integer types. Compilers should provide the functionalityfor 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 tothe 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 thefollowing sections.

Routines in support libraries must satisfy the following constraints:

Identical results must be returned when a routine is reinvoked with the same inputarguments.

Multiple calls with the same input arguments can be collapsed into a single call with acached result.

These properties permit a compiler to make assumptions about variable lifetimes across

library function calls: values in memory will not change, previously dereferenced pointersneed not be referenced again.

8/11/2019 ABI_4.0_Spec


8/11/2019 ABI_4.0_Spec




Libraries


Calling conventions Some of the runtime library functions use different calling conventions than the standardcalling conventions. Following definitions of calling conventions are used in thesubsequent list of runtime functions:

STD

The standard calling convention.

INTREG2

The standard calling convention, except hardware loop usage and the set of caller/calleesaved registers: only registers D0 and D1 are caller saved, i.e. destoyed by the runtimefunction. Registers D2.HL to D4.HL are saved by the runtime function, whereas D2.E toD4.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 returnvalue 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. Themost significant 32 bits are passed sign extended in the lower register, the least significant32 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 isreturned 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 singleunderscore.

For some routines there exist aliased names. A library has to provide all alternative namesfor a routine. Alternative names are denoted by a separating vertical bar (|).

Floating-point

routines

Conformant library support must include the following floating point routines.

8/11/2019 ABI_4.0_Spec




Libraries


The data formats are as specified in IEEE-754. The math routines are not required tocompute results as specified in IEEE-754. Implementation of these routines mustdocument the degree to which operations conform to the IEEE standard. Not all users offloating point require IEEE-754 precision and exception handling, and may not want toincur 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 truncatingany 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 thedouble 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 bytruncating any fractional part, and returns the unsigned integer value.

doubl e _d_utod( unsi gned i nt a) Calling convention: STD

Converts the unsigned integer value of a to double precision, and returnsthe 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 returnsthe 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 returnsthe 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 truncatingany 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 thesingle 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 bytruncating any fractional part, and returns the unsigned integer value.

8/11/2019 ABI_4.0_Spec




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 returnsthe single precision value.

f l oat _f _mul | __QFMul ( f l oat a, f l oat b) Calling convention: STD

Returnsa * 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 andb. 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

Performs an ordered comparison of the double precision values of a andb. 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

Performs an ordered comparison of the double precision values of a andb. 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

Performs an ordered comparison of the double precision values of a andb. 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 0otherwise.

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 andb. 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

Performs an ordered comparison of the single precision values of a and b.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

Performs an ordered comparison of the single precision values of a and b.Returns a 1 if a is less than or equal to b, and a 0 otherwise.

8/11/2019 ABI_4.0_Spec




Libraries


i nt _f _f l t | __QFCmpl t ( 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 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 ofa

andb. Returns a 1 if they are unordered or not equal; returns a 0 otherwise.

8/11/2019 ABI_4.0_Spec




Libraries


Integer and fractionalarithmetic routines

Conformant library support must include the following integer and fractional arithmeticroutines. 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 isundefined.

i nt __udi v16| __Qdi v16_u( unsi gned short a, unsi gned short 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 isundefined.

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

behavior is undefined.

i nt __ r em16| __Qmod16_s( short a, shor t b) Calling convention: INTREG2

Returns the remainder upon dividing a by b. If the divisor has the valuezero, 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 hasthe 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

zero, the behavior is undefined.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 hasthe 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 valuezero, the behavior is undefined.

8/11/2019 ABI_4.0_Spec




Libraries


Optional long longroutines

If the optional C l ong l ong data type is supported, then library support must also includethe 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 thesigned l ong l ong result. If the divisor has the value zero, the behavior isundefined.

unsi gned l ong l ong _UDi v64( unsi gned l ong l ong a, unsi gned l ongl ong b) Calling convention: DARG2

Computes the quotient a/ b, truncating any fractional part, and returns theunsigned l ong l ong result. If the divisor has the value zero, the

behavior is undefined.

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 signedl ong l ong result. If the divisor has the value zero, the behavior isundefined.

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 ongl ong b) Calling convention: DARG2

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 ongl ong b) Calling convention: DARG2

Computes the remainder upon dividing a by b, and returns the unsignedl ong l ong result. If the divisor has the value zero, the behavior isundefined.

l ong l ong _d_dt ol l ( doubl e a) Calling convention: STDConverts the double precision value of a to a signed l ong l ong bytruncating 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 bytruncating 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: STDConverts 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 bytruncating any fractional part, and returns the signed l ong l ong value.

8/11/2019 ABI_4.0_Spec




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 bytruncating 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 andrestoring functions

The library must contain functions for saving and restoring the function context. Thesefunctions may be used by the compiler instead of PUSH and POP instructions to reducecode 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 functionreturns, 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 JMP instruction at the end ofa 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 itreturns 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 leadingunderscores.

D5

D4

R5

R4

R7

R6 –24

–20

–16

–12

–8

–4

←SP

D7

D6

SR

–28

–32

–36

–40Return address

8/11/2019 ABI_4.0_Spec




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, R6and 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 estor e(voi d)This function must be the target of a BRA or JMP instruction at the end ofa function. It restores the callee-saved registers D6, D7, R6 and R7 andreturns through the caller return address stored at SP – 24. There is noneed for an RTS after calling the restoring function, since it returnsautomatically for the caller.

After calling the saving function __CW_SC100_cal l ee_r est or e, the stack framevalues relative to the address in the stack pointer (SP) will be:

Example 13. Saving and restoring functions usage example _f oo: bsr ___CW_SC100_cal l ee_save ; Save cal l ee- saved r egi st ers. 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 estore ; Restore cal l ee- saved r egi st ers ; and r et ur n t o cal l er of f oo.

C++ SupportFunctions

The StarCore C++ ABI is based on the generic C++ ABI. A conforming runtime libraryshall implement the functions and classes required by the C++ standard and the genericABI.

In addition to those classes, a C++ StarCore runtime library should implement thefollowing 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.

extern “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

8/11/2019 ABI_4.0_Spec




Libraries


extern “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.

extern "C" voi d *__r egi st er _gl obal _obj ect( )

extern "C" voi d __destr 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 ern "C" voi d __t hrow( )ext ern "C" voi d __r ethr ow( )ext ern "C" voi d __end_catch( )ext ern "C" voi d __unexpect ed( )

These functions are used for C++ exception handling.

8/11/2019 ABI_4.0_Spec




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. TheException Handling ABI is not based on the generic C++ ABI and it is documentedseparately.

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: DataLayout, 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 andDestruction 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 ObjectConstruction Order

The #pragma priority (as documented in section 3.3.4 of the generic ABI) is not required.

DSO ObjectDestruction API

The StarCore compiler uses proprietary functions for object destruction. These functionsare semantically equivalent with the generic ABI functions, but they should not be calledfrom 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, atermination 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 tocause 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. Thethird parameter (“memory”) is a pointer to a preallocated memory space, usually in thestatic 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):

exter n "C" voi d __dest r oy_gl obal _chai n( voi d)

8/11/2019 ABI_4.0_Spec




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 compatiblewith the high level generic C++ ABI specification.

External Names The external name of a C++ symbol is formed by prefixing an underscore character (_) tothe 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 arerequired to have a single definition. The compiler should assign a STB_MULTIDEFsymbol binding to such objects.

Multidef symbols resemble global symbols, but having multidef symbols with the samename in different module does not generate an error. The linker keeps only the objectassociated to the first symbol, in link order.

8/11/2019 ABI_4.0_Spec




C++ ABI


8/11/2019 ABI_4.0_Spec



Chapter 3 Object File Format

The executable and linking format (ELF) is used for representing the binary application tothe 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 highlightsdifferences between the ELF version 1.1 definition and the StarCore implementation.

This chapter focuses on the interface for relocatable and executable programs. Arelocatable program contains code suitable for linking to create another relocatable

program or executable program. An executable program contains binary informationsuitable for loading and execution on a target processor.

Interface Descriptions

ELF presents two views of binary data, as shown in Figure 2:

The linking view provides data in a format suitable for incremental linking into arelocatable 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 executionview, segments are the primary sources of information. Sections may be present but arenot 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

SegmentsSections

... ...

Section header table Optional section header table

8/11/2019 ABI_4.0_Spec



Object File Format February 2007

The ELF Header


The ELF Header

The ELF header structure is shown in Example 14. This structure and its fields are defined by the ELF version 1.1 specification. StarCore-specific code is shown in Example 15.

Example 14. ELF header structuret ypedef st r uct { unsi gned char e_i dent [ EI _NI DENT]; El f 32_Hal f e_type; El f 32_Hal f e_machi ne; El f 32_Word 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_Word 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 ;

Example 15. StarCore specificse_i dent[ EI _CLASS] = ELFCLASS32e_i dent [ EI _DATA] = ELFDATA2LSB ( l i t t l e- endi an memory mode)e_i dent [ EI _DATA] = ELFDATA2MSB (bi g-endi an memory 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#def i ne EF_STARCORE_CORE_1_MAC 1#def i ne EF_STARCORE_CORE_2_MAC 2

Mixing object files with with different code features will result in an object file with thehighest number of MAC units. For example, mixing EF_STARCORE_CORE_2_MAC andEF_STARCORE_CORE_4_MAC will result in an object file withEF_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#def i ne EF_STARCORE_CORE_REV_SC2000_V4 4#def i ne EF_STARCORE_CORE_REV_SC3000_V5 5

Mixing object files with different core architectures will result in an object file with thehighest core architecture value.

Bits 12-17: The ABI version. The defined ABI versions are:

8/11/2019 ABI_4.0_Spec



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#def i ne EF_STARCORE_ABI _3_0 3#def i ne EF_STARCORE_ABI _4_0 4

Linking with different ABI versions or with non-conforming object files may result inlinker errors or undetermined output.

Bits 18-31: Zero. Reserved for future use.

Example 16. 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) )

8/11/2019 ABI_4.0_Spec




Sections


Sections

Sections are the main components of the ELF file. Section headers define all theinformation about a section. A section header is shown in Example 17. It is identical to the

ELF version 1.1 definition.

Example 17. Section header structure

t ypedef st r uct {El f 32_Wor d sh_name;El f 32_Word sh_t ype;El f 32_Word sh_f l ags;El f 32_Addr sh_addr ;El f 32_Of f sh_of f set ;El f 32_Word sh_si ze;El f 32_Word sh_l i nk;El f 32_Word sh_i nf o;

El f 32_Word sh_addral i gn;El f 32_Word sh_ent si ze;

} El f 32_Shdr;

8/11/2019 ABI_4.0_Spec




Sections


Sections used in StarCore ELF binaries are listed in Table 6. The section names listed inthis 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 data1

. zbss SHT_NOBI TS SHF_ALLOC, SHF_WRI TE Zero Data Area uninitialized data1

. r e l asection SHT_RELA None Relocation info for secti on2

. 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_abbrev SHT_PROGBI TS None Abbreviation tables4

. debug_aranges SHT_PROGBI TS None Address range tables4

. debug_ f rame SHT_PROGBI TS None Call frame information4

. debug_i nf o SHT_PROGBI TS None Debugging information entries4

. debug_l i ne SHT_PROGBI TS None Line number information4

. debug_l oc SHT_PROGBI TS None Location lists4

. debug_maci nf o SHT_PROGBI TS None Macro information4

. debug_pubnames SHT_PROGBI TS None Global name tables4

. SC100. del ay_sl ots SHT_PROGBI TS None Static delay slot information5

1The contents of the .bss and .zbss sections are zeroed when loaded.2See “Relocation” on page 72.3See “NOTE Section” on page 91.4This information is in DWARF2 format.5See “Special Sections” on page 68.

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

8/11/2019 ABI_4.0_Spec




Special Sections


Special Sections

.SC100.delay_slots A debug section called . SC100. del ay_sl ot s is used to hold all static delay slotinformation for each StarCore executable file. Assemblers must identify and generatesufficient relocatable file information (sections and relocation entries) to support thisfeature; linkers should need no special knowledge of this feature when creating executablefiles. Assemblers must also populate this section when creating executable files inabsolute 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 ormore operands. No special headers, padding, alignment, or sequence terminators arerequired.

Opcodes are represented by a single unsigned byte (8 bit) value. To accommodate futureexpansion without breaking existing readers, 4 bits are used for a unique ID (provides 16opcodes) and 4 bits are used to indicate the size in bytes for the operands (provides up to15 bytes of operands).

Three opcode IDs are initially required; additional IDs may be added later to support suchfeatures as overlays and position independent code. The required opcode IDs are:

SDS_EXPLI CI T_OP (explicit “delayed” instructions, for example, JSRD).

Accepts two unsigned word (32 bits) operands. The first is the address of the explicitVariable Length Execution Set (VLES), and the second is the address of the delay slotVLES.

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 thelast 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 firstVLES, 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 potentiallyneeded 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.

Example 18 and Example 19 define the opcode IDs and the macros for accessing opcode parts.

Example 18. 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

8/11/2019 ABI_4.0_Spec




Special Sections


Example 19. 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 thefollowing 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 prefixholding 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 fordead-data stripping

Example:

l ab1 type I NI TI ALI ZERl ab2 t ype VARI ABLE

secti 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 000b 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.

8/11/2019 ABI_4.0_Spec




Special Sections


The .rom_init_tables section starts with a vector of 8-byte entries - one for each relevantsection:

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_initdirective.

• __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 endswith 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 secti on i n bytes*/

}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 sectioncontains two symbols __overlay_table and __overlay_count, where:

__overlay_table is an array of type Elf32_Ovl (see below), that contains an entry for eachoverlay 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; / *overl ay run 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 bytes of t he over l ay sect i on*/El f 32_Word ovl _checksum; / *checksumof t he over l ay data*/El f 32_Word ovl _f l ags; / *overl ay f l ags, used by the overl ay manager* /El f 32_Wor d ovl _other ; / *other i nf ormati 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 overl ay*/El f 32_Hal f ovl _chi l d; / *f i rst chi l d overl ay*/

8/11/2019 ABI_4.0_Spec




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 deadstripping and in this case linker creates the .ovltab section.

The elf type of .ovltab is SHT_STARCORE_OVLTAB.

8/11/2019 ABI_4.0_Spec




Relocation


Relocation

Each section which contains relocatable data has a corresponding relocation section oftype 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 relocationsapply. The sh_l i nk field of the relocation section defines the section header index of theassociated symbol table. If section names are used, the name of the relocation section is. r e l 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 asshown in Example 20. The r_offset field defines an offset into the data section to whichthe individual relocation applies. The r _ i nf o field specifies both the type of therelocation 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 macroand the symbol number is extracted using the ELF32_R_SYMmacro. The r _ i nf o field issynthesized 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 thelocation defined by the r_offset field (in the format specified by the relocation type).For a relocation type in Table 7, the relocation value is computed by adding the signedvalue 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 issimply the value of the r _addend field. This degenerate case is also often used by theextended relocation types defined in “Relocation stack” on page 86, particularlyR_STARCORE_OPER and R_STARCORE_POP, for which a symbol value is rarely useful.

Example 20. Relocation entry defined with Elf32_Rela

t ypedef st r uct { El f 32_Addr r _of f set ; El f 32_Word r _i nf o; El f 32_Sword 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 ) &0xff ) )

Relocation types Device-specific relocations describe how a memory location should be patched by thelinker. 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 thatthe operand meets the range and alignment requirement specified by the relocation.

For each relocation type in Table 7, the Type field indicates the value extracted usingELF32_R_TYPE, both as a number and as a standard C preprocessor symbol. A briefabstract of the relocation follows in parentheses.

The Size field indicates the number of bits used to represent the relocation value. If theoperand range is a subset of the values which can be represented in these bits, thatrestriction is indicated in parentheses.

8/11/2019 ABI_4.0_Spec




Relocation


The Signedness field indicates whether the relocation value is treated as signed orunsigned.

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 isencoded. The shift count subtracted from the size is the number of bits used to encode therelocation value.

The Overflow field indicates whether the relocation type checks the relocation value foroverflow. A calculated relocation value can be larger than the intended field, and therelocation type can verify the value range or truncate the result. In case of verify arelocation value has to be in range otherwise an error message is issued. Truncationsimply cuts off the exceeding bits and fits the result into the intended field, while issuing awarning message. Note that an overflow can not occur for 32 bit relocations, because theinternal 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 towhich the relocation applies (computed by adding the relocation's r_offset field and thedata section's sh_addr field), not the machine's runtime PC value (see “Instructionaddress vs. VLES address” on page 89).

The Encoding field indicates the way the relocation value is encoded in the target memorylocations. The order of the bits in the instruction operand or data value encoding does notnecessarily match the order of the bits in the relocation value. Upper case letters are usedto indicate relocation value bits which are more significant than bits indicated by lowercase letters. s and S denote bits of a signed relocation value, u and U denote bits of anunsigned relocation value, and x denotes a bit of a relocation value that is either signed orunsigned. 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-bitdirect) 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 19–15 and the ss represent bits 14–0 of the relocationvalue. 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

8/11/2019 ABI_4.0_Spec




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

8/11/2019 ABI_4.0_Spec




Relocation


Type: 4, R_STARCORE_R9_1_ 1 (9-bit PC-relative)

Size: 9

Signedness: Signed

Alignment: 1Shift: 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

Type: 5, R_STARCORE_R11_1_1 (11-bit PC-relative)

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: - - - - - - - - s ss - - - - - - - - s s ssssssssssS

111 1119876543211

543 210 6


performed.

Applies to: BREAK label; CONT label; CONTD label; DOSETUPn label; SKIPLS label

Table 7. Relocation type definitions (Continued)

8/11/2019 ABI_4.0_Spec




Relocation



Size: 21

Signedness: Signed


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: - - - - - - - - - s sss sss

6543210

Applies to: MOVE.W #s7,DR


Size: 15

Signedness: Signed

Alignment: 0

Shift: 0

Overflow: Verify

Encoding: - - - - - - - - - s s - - - - - - - - s s sssssssssss

11 1119876543210

43 210

Applies to: MOVE.B DR,(Rn+s15); MOVE.B DR,(SP+s15); MOVE.B (SP+s15),DR; MOVEU.B (Rn+s15),DR;

MOVEU.B (SP+s15),DR


8/11/2019 ABI_4.0_Spec




Relocation



Size: 15

Signedness: Signed


Overflow: Verify


11 1119876543210

43 210

Applies to: MOVE.F (Rn+s15),Db; MOVE.F (SP+s15),Db; MOVE.W C4,(SP+s15); MOVE.W DR,(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: 15Signedness: 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;

Type: 12, R_STARCORE_S16_0_0 (16-bit signed)Size: 16

Signedness: Signed

Alignment: 0

Shift: 0

Overflow: Verify

Encoding: - - - - - - - - s ss - - - - - - - - s s sssssssssss

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


8/11/2019 ABI_4.0_Spec




Relocation



Size: 16

Signedness: Signed


Overflow: Verify

Encoding: - - - - - - - - s s s - - - - - - - - s s sssssssssss

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: - - - - - - - - - - - s s - - - - - - - - - - - - - - - - - - - - - s s s s s s s s s s s s s s

11 11119876543210

54 3210

Applies to: MOVE.W #s16,(a16); MOVE.W #s16,(SP+sa16)

Type: 15, R_STARCORE_S32_0_0 (32-bit signed)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


8/11/2019 ABI_4.0_Spec




Relocation


Type: 16, R_STARCORE_U4_1_1 (4-bit unsigned)

Size: 4

Signedness: Unsigned


Overflow: Verify

Encoding: - - - - - - - - - - - - - uuu

321

Applies to: MOVE.W DR,(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: - - - - - - - - - - - u u u u u

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: 1Overflow: Verify

Encoding: - - - - - - - - - - - u u u u u

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)


8/11/2019 ABI_4.0_Spec




Relocation



Size: 6



Overflow: Verify

Encoding: - - - - - - - - - -uuuuuu

543210

Applies to: DOENn #u6; DOENSHn #u6


Size: 7


Alignment: 1

Shift: 1

Overflow: Verify


654321

Applies to: MOVE.W DR,(SP-u6); MOVE.W (SP-u6),DR


Size: 8


Alignment: 2

Shift: 2

Overflow: Verify


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


8/11/2019 ABI_4.0_Spec




Relocation


Type: 24, R_STARCORE_W6_0_0 (6-bit unsigned)

Size: 6 (range 0..39)



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.B DR,(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.W C4,(a16); MOVE.W (a16),C4; MOVE.W #s16,(a16); MOVES.F Db,(a16);

MOVEU.W (a16),C4; NOT.W (a16); OR.W #u16,(a16)


8/11/2019 ABI_4.0_Spec




Relocation



Size: 16



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)


8/11/2019 ABI_4.0_Spec




Relocation


Type: 30, R_STARCORE_O16_0_0 (16-bit unsigned)

Size: 16



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: JF label; JFD label; JMP label; JMPD label; JSR label; JSRD label; JT label; JTD label;

MOVE.F (a32),Db; MOVE.W DR,(a32); MOVE.W (a32),DR; MOVES.F Db,(a32); MOVEU.W (a32),DR;


8/11/2019 ABI_4.0_Spec




Relocation



Size: 32



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

Type: 34, R_STARCORE_U32_16_16 (32-bit unsigned)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


8/11/2019 ABI_4.0_Spec




Relocation


Type: 36, R_STARCORE_U32_0_0_AA (32-bit unsigned)

Size: 32



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


8/11/2019 ABI_4.0_Spec




Relocation


Relocation stack For those situations in which the relocation value cannot be expressed as a simple symbolvalue plus an addend, there are three special relocation types used to evaluate an arbitraryexpression 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


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: 20Signedness: 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 - - - - u u u u

4 3210


Applies to: CMPEQA.W #u5,Rn; CMPGTA.W #u5,Rn


8/11/2019 ABI_4.0_Spec




Relocation


A relocation stack is a standard last-in-first-out data structure containing 32-bit values. Ahosted environment must not place any arbitrary limit on the depth of the stack. Anembedded environment may impose any limit on stack depth or omit the relocation stackentirely (effectively, a maximum stack depth of zero).

A relocation type of 252 (R_STARCORE_PUSH_PC) indicates that the sum of the symbolvalue (the value of symbol number zero is zero) plus the signed r _addend value plus thecurrent 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.

8/11/2019 ABI_4.0_Spec




Relocation


A relocation type of 254 (R_STARCORE_OPER) defines an operation to be performed onone or more stack values. The operation is specified by the sum of the symbol value (thevalue of symbol number zero is zero) plus the signed r _addend value. Operations areshown in Table 8. In the table, Stack0 indicates the value on the top of the stack, andStack1 indicates the value one level beneath the top of the stack.

Note that in most cases, the stack values are treated as unsigned. However, arithmeticshifts 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 Table 7. The relocation type isspecified by the sum of the symbol value (the value of symbol number zero is zero) plusthe 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 isalways unaffected.

Arithmetic shift right:Copies of the most significant bit are shifted in on the left.

8/11/2019 ABI_4.0_Spec




Relocation


When the R_STARCORE_POP operation is encountered, there should be exactly one valueon the stack. This value, which is consumed by this operation, becomes the new relocationvalue 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 anR_STARCORE_POP, before an ordinary relocation, and after linking is complete. Asequence of relocations which causes a stack underflow does not conform to the ABI.

Instruction addressvs. VLES address

Within a variable-length execution set (VLES), all instructions share a common value ofthe PC register, specifically the starting address of the VLES itself. The r_offset fieldof a relocation points to the instruction address, not the VLES address. To compensate forthis, 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 ther _addend field. Example:

The “dosetup3” instruction would generate an ordinary relocation with the followingfield values:

r _i nf o: ELF32_R_I NFO( <symbol number of l ptab>, 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 ptab+32

]

8/11/2019 ABI_4.0_Spec




Relocation


2. In an extended relocation, the subtraction of the offset should be inserted at the end ofrelocation expression, just before the R_STARCORE_POP operation. Example:

The “dosetup3” instruction would generate a sequence of extended relocations with thefollowing 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 dosetup3 l ptab+4*ndx

]

r_info (type shown first, then symbol) r_addend

R_STARCORE_PUSH <symbol number of l ptab> 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

8/11/2019 ABI_4.0_Spec




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 Figure 3. It consists of the following:

Figure 3. Vendor identification note format

Object file comments generated by the user through an assembler directive are placed inthe note section. This is typically for users to identify their object code. The same stringtermination and padding restrictions apply to object file comments as apply to vendoridentification 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-byteunsigned integer.

descz The size of the description entries. This is 12 bytes for the vendor id note. Thedescription 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 boundaryalignment which represents the vendor’s 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

8/11/2019 ABI_4.0_Spec




NOTE Section


The object file comment format is shown in Figure 4.

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

8/11/2019 ABI_4.0_Spec




Program Headers


Program Headers

Program headers are used to build an executable image in memory and are only useful forexecutable files. While section headers may or may not be included in executable files,

program headers are always present. See Example 21 for a sample program header.

Example 21. Program headert ypedef st r uct { El f 32_Word 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_Word p_f l ags; El f 32_Word 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 segment’s file image. (May be zero.)p_memsz Gives the number of bytes in segment’s 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.

8/11/2019 ABI_4.0_Spec




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 registernumber mapping

Table 9 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 1–16 D0–D15

Address Registers 17–32 R0–R15

Data Registers—extension portion 33–48 D0_e–D15_e

Data Registers—high portion 49–64 D0_h–D15_h

Data Registers—low portion 65–80 D0_l–D15_l

Loop Counter Registers 81–84 LC0–LC3

Modulo Registers 85–88 M0–M3

Offset Registers 89–92 N0–N3

Program Counter 93 PC

Clock Control Registers 94–97 PCTL0–PCTL3

Start Address Registers 98–101 SA0–SA3

Vector Base Address Register 102 VBA

Exception and Mode Register 103 EMR

Modifier Control Register 104 MCTL

8/11/2019 ABI_4.0_Spec


ABI_4.0_Spec

Documents

Transcript of ABI_4.0_Spec