JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
SPARC Assembly Language Reference Manual     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information

Preface

1.  SPARC Assembler Syntax

2.  Executable and Linking Format

3.  Directives and Pseudo-Operations

4.  Creating Data in Assembler

5.  SPARC Code Models

5.1 Basics

5.2 Address Sizes

5.2.1 32-Bit Absolute

5.2.2 64-Bit Absolute

5.2.3 44-Bit Absolute

5.2.4 64-Bit with 13-Bit PIC

5.2.5 64-Bit With 32-Bit PIC

5.3 Global Object Table (GOT) Code Models

5.4 Thread Local Storage (TLS) Code Models

5.4.1 Local Executable Code Model

5.4.2 Initial Executable Code Model

5.4.3 Local Dynamic TLS Code Model

5.4.4 General Dynamic TLS Code Model

6.  Writing Functions -- The SPARC ABI

7.  Assembler Inline Functions and __asm Code

A.  Using the Assembler Command Line

B.  A Sample Assembler Program

C.  SPARC Instruction Sets and Mnemonics

Index

5.3 Global Object Table (GOT) Code Models

On SPARC processors, position independent code (PIC) uses a global object table (GOT) for loading addresses, so that the addresses can be determined at run-time by the dynamic linker.

For some data items, a faster access is possible by using the GOTdata relocations.

There are two different code models for GOTdata, plain GOTdata, and GOTdata_op.

Here is the code for the GOTdata_op code model.

add:
.L900000105:
        rd      %pc,%o1
        sethi   %pc22(_GLOBAL_OFFSET_TABLE_-(.L900000105-.)),%g1
        add     %g1,%pc10(_GLOBAL_OFFSET_TABLE_-(.L900000105-.)),%g1
        add     %g1,%o1,%o1
        sethi   %gdop_hix22(sum),%o3
        xor     %o3,%gdop_lox10(sum),%o2
        ldx     [%o1+%o2],%g4,%gdop(sum)
        ld      [%g4],%g5
        add     %g5,%o0,%g3
        retl
        st      %g3,[%g4]
        .type   add,#function
        .size   add,(.-add)

There are four instructions to form a pointer to the GOT into register %o1. Then it takes two more instructions to form the offset of the address of sum in the GOT (in %o2), and another instruction to add those to the address of the GOT to form the address of the GOT slot for sum, and load that address into %g4.

At this point, the code looks much like the pic32 code model.

The operators act like this:

%gdop_hix22(sum) --> R_SPARC_GOTDATA_OP_HIX22
%gdop_lox10(sum) --> R_SPARC_GOTDATA_OP_LOX10
%gdop(sum)       --> R_SPARC_GOTDATA_OP

The difference for the GOTdata_op code model is that the static linker, ld, can re-write the code sequence to avoid one load from the GOT. This can happen if the distance from the beginning of the GOT to the location of sum is less than 2 GB away.

So, then the load:

ldx     [%o1+%o2],%g4,%gdop(sum)

is re-written into an add:

 add     %o1,%o2,%g4

Here is the code for the plain GOTdata code model.

add:
.L900000105:
        rd      %pc,%o1
        sethi   %pc22(_GLOBAL_OFFSET_TABLE_-(.L900000105-.)),%g1
        add     %g1,%pc10(_GLOBAL_OFFSET_TABLE_-(.L900000105-.)),%g1
        add     %g1,%o1,%o1
        sethi   %gd_hix22(sum),%o3
        xor     %o3,%gd_lox10(sum),%o2
        ld      [%o1+%o2],%g5
        add     %g5,%o0,%g3
        retl
        st      %g3,[%o1+%o2]
        .type   add,#function
        .size   add,(.-add)

There are four instructions to form a pointer to the GOT into register %o1. Then it takes two more instructions to form the offset of the address of sum in the GOT (in %o2). Now the sum of %o1 and %o2 can be used directly to load the value of sum.

The operators act like this:

%gd_hix22(sum) --> R_SPARC_GOTDATA_HIX22
%gd_lox10(sum) --> R_SPARC_GOTDATA_LOX10

The plain GOTdata code is simpler than the GOTdata_op code, but it requires that the data be within 2 GB of the start of the GOT, otherwise a static link-time error will result.