On 15.10.2010, at 22:56, Andreas Färber wrote:
Am 15.10.2010 um 22:28 schrieb Alexander Graf:
On 15.10.2010, at 22:22, Andreas Färber wrote:
Am 15.10.2010 um 12:26 schrieb Alexander Graf:
On 15.10.2010, at 00:38, Alexander Graf wrote:
/* saving non-volatile registers */
- stw r13, 8(r4)
I would recommend multiplying here:
stw r13, (3 * 4)(r4)
That makes it more readable.
- stw r14, 12(r4)
- stw r15, 16(r4)
- stw r16, 20(r4)
- stw r17, 24(r4)
- stw r18, 28(r4)
- stw r19, 32(r4)
- stw r20, 36(r4)
- stw r21, 40(r4)
- stw r22, 44(r4)
- stw r23, 48(r4)
- stw r24, 52(r4)
- stw r25, 56(r4)
- stw r26, 60(r4)
- stw r27, 64(r4)
- stw r28, 68(r4)
- stw r29, 72(r4)
- stw r30, 76(r4)
- stw r31, 80(r4)
Actually thinking about this a bit more, r13-r31 are already defined non-volatile by the C ABI, so you can be sure that the C function you're calling doesn't clobber them. You don't need to manually save/restore them :).
The OF client interface saves r5-r31 as well as ctr, cr and xer. It shouldn't hurt to save more registers than necessary to assert the requirements of the CHRP spec [1]:
<<< 7.2.2 Register Usage
Requirements:
7–10. Except as required by a specific function, RTAS must not modify the following operating environment registers: TB, DEC, SPRG0-SPRG3, EAR, DABR, SDR1, ASR, SR0-SR15, FPSCR, FPR0-FPR3, and any processor specific registers.
Read: no timers, no paging, no modification of page fault handler registers
7-11. RTAS must preserve the following user mode registers: R1-R2, R13-R31, and CR.
Except for CR, C is the same. So you really only need to save/restore cr :).
Huh? Doesn't that depend on the ABI used rather than on C? If someone uses a differently configured GCC (or clang or ...), such assumptions might not hold.
I thought we're using the Linux ABI internally?
What about r3-r4? The SysV ABI ppc supplement has them listed as volatile, so if I want to continue to access the private data area, I still need to save and restore r4, no?
r3 and r4 are volatile, yes. But those are not listed in the paragraphs here either :).
Alex