1 | # |
---|
2 | # $Id$ |
---|
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. |
---|