blob: 0c481d67c1dc5af1569c9bf4cc03a50550d485c1 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
#
# $Id$
#
This file discusses SPARC specific issues which are important to
this port. The primary topics in this file are:
+ Global Register Usage
+ Stack Frame
+ EF bit in the PSR
Global Register Usage
=====================
This information on register usage is based heavily on a comment in the
file gcc-2.7.0/config/sparc/sparc.h in the the gcc 2.7.0 source.
+ g0 is hardwired to 0
+ On non-v9 systems:
- g1 is free to use as temporary.
- g2-g4 are reserved for applications. Gcc normally uses them as
temporaries, but this can be disabled via the -mno-app-regs option.
- g5 through g7 are reserved for the operating system.
+ On v9 systems:
- g1 and g5 are free to use as temporaries.
- g2-g4 are reserved for applications (the compiler will not normally use
them, but they can be used as temporaries with -mapp-regs).
- g6-g7 are reserved for the operating system.
NOTE: As of gcc 2.7.0 register g1 was used in the following scenarios:
+ as a temporary by the 64 bit sethi pattern
+ when restoring call-preserved registers in large stack frames
RTEMS places no constraints on the usage of the global registers. Although
gcc assumes that either g5-g7 (non-V9) or g6-g7 (V9) are reserved for the
operating system, RTEMS does not assume any special use for them.
Stack Frame
===========
The stack grows downward (i.e. to lower addresses) on the SPARC architecture.
The following is the organization of the stack frame:
| ............... |
fp | |
+-------------------------------+
| |
| Local registers, temporaries, |
| and saved floats | x bytes
| |
sp + x +-------------------------------+
| |
| outgoing parameters past |
| the sixth one | x bytes
| |
sp + 92 +-------------------------------+ *
| | *
| area for callee to save | *
| register arguments | * 24 bytes
| | *
sp + 68 +-------------------------------+ *
| | *
| structure return pointer | * 4 bytes
| | *
sp + 64 +-------------------------------+ *
| | *
| local register set | * 32 bytes
| | *
sp + 32 +-------------------------------+ *
| | *
| input register set | * 32 bytes
| | *
sp +-------------------------------+ *
* = minimal stack frame
x = optional components
EF bit in the PSR
=================
The EF (enable floating point unit) in the PSR is utilized in this port to
prevent non-floating point tasks from performing floating point
operations. This bit is maintained as part of the integer context.
However, the floating point context is switched BEFORE the integer
context. Thus the EF bit in place at the time of the FP switch may
indicate that FP operations are disabled. This occurs on certain task
switches, when the EF bit will be 0 for the outgoing task and thus a fault
will be generated on the first FP operation of the FP context save.
The remedy for this is to enable FP access as the first step in both the
save and restore of the FP context area. This bit will be subsequently
reloaded by the integer context switch.
Two of the scenarios which demonstrate this problem are outlined below:
1. When the first FP task is switched to. The system tasks are not FP and
thus would be unable to restore the FP context of the incoming task.
2. On a deferred FP context switch. In this case, the system might switch
from FP Task A to non-FP Task B and then to FP Task C. In this scenario,
the floating point state must technically be saved by a non-FP task.
|
