[OpenBIOS] [PATCH, RFC] ppc: Turn 32-bit ppc64 into a config option, to be deprecated
Blue Swirl
blauwirbel at gmail.com
Wed Nov 17 20:58:47 CET 2010
On Wed, Nov 17, 2010 at 7:45 PM, Andreas Färber <andreas.faerber at web.de> wrote:
> Am 17.11.2010 um 02:32 schrieb Alexander Graf:
>
>> On 14.11.2010, at 02:48, Andreas Färber wrote:
>>
>>> Having 64-bit support as an option allows users to disable
>>> and test it before it gets officially removed.
>>>
>>> Fork single-bitness macros EXCEPTION_{PREAMBLE,EPILOGUE}:
>>> Use assembler macros for things that are constant to avoid
>>> ; and \, and use preprocessor macros to handle differences.
>>> Adopt QEMU coding style for new code.
>>>
>>> Functional changes for ppc64:
>>> * Don't clear MSR in preamble.
>>> * Just save the minimum number of registers since 64-bit code will
>>> save the full registers.
>>> * Reserve 48 bytes of stack frame space for ppc64, according to
>>> 64-bit PowerPC ELF ABI supplement 1.9.
>>> * Use RFI macro.
>>>
>>> Cc: Alexander Graf <agraf at suse.de>
>>> Signed-off-by: Andreas Färber <andreas.faerber at web.de>
>>> ---
>>> arch/ppc/qemu/init.c | 4 ++
>>> arch/ppc/qemu/start.S | 92
>>> +++++++++++++++++++++++++++++++++++++++-
>>> config/examples/ppc_config.xml | 1 +
>>> 3 files changed, 96 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c
>>> index 0b781d9..d17c843 100644
>>> --- a/arch/ppc/qemu/init.c
>>> +++ b/arch/ppc/qemu/init.c
>>> @@ -303,6 +303,7 @@ cpu_g4_init(const struct cpudef *cpu)
>>> fword("finish-device");
>>> }
>>>
>>> +#ifdef CONFIG_PPC_64BITSUPPORT
>>> /* In order to get 64 bit aware handlers that rescue all our
>>> GPRs from getting truncated to 32 bits, we need to patch the
>>> existing handlers so they jump to our 64 bit aware ones. */
>>> @@ -322,6 +323,7 @@ ppc64_patch_handlers(void)
>>> asm ( "icbi 0, %0" : : "r"(dsi) );
>>> asm ( "icbi 0, %0" : : "r"(isi) );
>>> }
>>> +#endif
>>>
>>> static void
>>> cpu_970_init(const struct cpudef *cpu)
>>> @@ -341,10 +343,12 @@ cpu_970_init(const struct cpudef *cpu)
>>>
>>> fword("finish-device");
>>>
>>> +#ifdef CONFIG_PPC_64BITSUPPORT
>>> /* The 970 is a PPC64 CPU, so we need to activate
>>> * 64bit aware interrupt handlers */
>>>
>>> ppc64_patch_handlers();
>>> +#endif
>>>
>>> /* The 970 also implements the HIOR which we need to set to 0 */
>>>
>>> diff --git a/arch/ppc/qemu/start.S b/arch/ppc/qemu/start.S
>>> index e86bdfd..6cf20cf 100644
>>> --- a/arch/ppc/qemu/start.S
>>> +++ b/arch/ppc/qemu/start.S
>>> @@ -14,6 +14,7 @@
>>> *
>>> */
>>>
>>> +#include "autoconf.h"
>>> #include "asm/asmdefs.h"
>>> #include "asm/processor.h"
>>>
>>> @@ -24,6 +25,8 @@
>>> #define ILLEGAL_VECTOR( v ) .org __vectors + v ; vector__##v: bl
>>> trap_error ;
>>> #define VECTOR( v, dummystr ) .org __vectors + v ; vector__##v
>>>
>>> +#ifdef CONFIG_PPC_64BITSUPPORT
>>> +
>>> /* We're trying to use the same code for the ppc32 and ppc64 handlers
>>> here.
>>> * On ppc32 we only save/restore the registers, C considers volatile.
>>> *
>>> @@ -176,6 +179,89 @@
>>> #undef stl
>>> #undef ll
>>>
>>> +#else
>>> +
>>> +#ifdef __powerpc64__
>>> +
>>> +#define ULONG_SIZE 8
>>> +#define STACKFRAME_MINSIZE 48
>>> +#define stl std
>>> +#define ll ld
>>> +
>>> +#else
>>> +
>>> +#define ULONG_SIZE 4
>>> +#define STACKFRAME_MINSIZE 16
>>> +#define stl stw
>>> +#define ll lwz
>>> +
>>> +#endif
>>> +
>>> +.macro EXCEPTION_PREAMBLE
>>> + mtsprg1 r1 /* scratch */
>>> + mfsprg0 r1 /* exception stack in sprg0 */
>>> + addi r1, r1, -(20 * ULONG_SIZE) /* push exception frame */
>>> +
>>> + stl r0, ( 0 * ULONG_SIZE)(r1) /* save r0 */
>>> + mfsprg1 r0
>>> + stl r0, ( 1 * ULONG_SIZE)(r1) /* save r1 */
>>> + stl r2, ( 2 * ULONG_SIZE)(r1) /* save r2 */
>>> + stl r3, ( 3 * ULONG_SIZE)(r1) /* save r3 */
>>> + stl r4, ( 4 * ULONG_SIZE)(r1)
>>> + stl r5, ( 5 * ULONG_SIZE)(r1)
>>> + stl r6, ( 6 * ULONG_SIZE)(r1)
>>> + stl r7, ( 7 * ULONG_SIZE)(r1)
>>> + stl r8, ( 8 * ULONG_SIZE)(r1)
>>> + stl r9, ( 9 * ULONG_SIZE)(r1)
>>> + stl r10, (10 * ULONG_SIZE)(r1)
>>> + stl r11, (11 * ULONG_SIZE)(r1)
>>> + stl r12, (12 * ULONG_SIZE)(r1)
>>> +
>>> + mflr r0
>>> + stl r0, (13 * ULONG_SIZE)(r1)
>>> + mfcr r0
>>> + stl r0, (14 * ULONG_SIZE)(r1)
>>> + mfctr r0
>>> + stl r0, (15 * ULONG_SIZE)(r1)
>>> + mfxer r0
>>> + stl r0, (16 * ULONG_SIZE)(r1)
>>> +
>>> + /* 76(r1) unused */
>
> This comment is obviously outdated, just like in the old code path.
>
>>> +
>>> + addi r1, r1, -STACKFRAME_MINSIZE /* C ABI saves LR and SP */
>>> +.endm
>>> +
>>> +.macro EXCEPTION_EPILOGUE
>>> + addi r1, r1, STACKFRAME_MINSIZE /* pop ABI frame */
>>> +
>>> + ll r0, (13 * ULONG_SIZE)(r1)
>>> + mtlr r0
>>> + ll r0, (14 * ULONG_SIZE)(r1)
>>> + mtcr r0
>>> + ll r0, (15 * ULONG_SIZE)(r1)
>>> + mtctr r0
>>> + ll r0, (16 * ULONG_SIZE)(r1)
>>> + mtxer r0
>>> +
>>> + ll r0, ( 0 * ULONG_SIZE)(r1)
>>> + ll r2, ( 2 * ULONG_SIZE)(r1)
>>> + ll r3, ( 3 * ULONG_SIZE)(r1)
>>> + ll r4, ( 4 * ULONG_SIZE)(r1)
>>> + ll r5, ( 5 * ULONG_SIZE)(r1)
>>> + ll r6, ( 6 * ULONG_SIZE)(r1)
>>> + ll r7, ( 7 * ULONG_SIZE)(r1)
>>> + ll r8, ( 8 * ULONG_SIZE)(r1)
>>> + ll r9, ( 9 * ULONG_SIZE)(r1)
>>> + ll r10, (10 * ULONG_SIZE)(r1)
>>> + ll r11, (11 * ULONG_SIZE)(r1)
>>> + ll r12, (12 * ULONG_SIZE)(r1)
>>> +
>>> + ll r1, ( 1 * ULONG_SIZE)(r1) /* restore stack at last */
>>> + RFI
>>> +.endm
>>
>>
>> I don't think this really belongs in this patch, no? :)
>
> --verbose please. The description is pretty clear on what this patch does
> and why.
>
> RFI was committed in r955, so can be used here.
>
> It doesn't make sense to me to #ifdef out code without providing the
> equivalent code path for ppc64, so this new code path does belong here
> (remember you agreed that having two parallel code paths was supposedly the
> only way for migration?).
>
> If you're referring to the suggested use of a .macro, please discuss this
> with Blue in general and not some hundred lines down a patch without
> referring to the commit message where this is discussed. Blue has been
> asking me to turn preprocessor macros into C inline functions - this
> construct here seems the closest equivalent in assembler code and the
> advantages I see are detailed in the commit message. You have not yet voiced
> any particular reason to make this a preprocessor macro, other than your
> personal preference for preprocessor macros, which appears to conflict with
> Blue's dislike of preprocessor macros and my dislike of unnecessary
> multi-line preprocessor macros.
I was going to comment that actually I haven't seen much gas macro use
in Linux. But then I ran grep and while there really are no macros for
Sparc (or x86_64), other architectures use them a lot. So macros are
OK for me.
More information about the OpenBIOS
mailing list