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