[PATCH v3 4/5] powerpc/lib/sstep: Add prty instruction emulation

Michael Ellerman mpe at ellerman.id.au
Fri Jul 28 11:31:00 AEST 2017


Matt Brown <matthew.brown.dev at gmail.com> writes:

> On Thu, Jul 27, 2017 at 11:26 AM, Michael Ellerman <mpe at ellerman.id.au> wrote:
>> Segher Boessenkool <segher at kernel.crashing.org> writes:
>>
>>> On Wed, Jul 26, 2017 at 08:03:30PM +1000, Michael Ellerman wrote:
>>>> Segher Boessenkool <segher at kernel.crashing.org> writes:
>>>> > A general question about these patches: some things are inside #ifdef
>>>> > __powerpc64__, some are not.  It seems it is the wrong macro, and it
>>>> > should be used (or not used) consistently?
>>>>
>>>> Why is it the wrong macro? Because we tend to use CONFIG_PPC64 you mean?
>>>
>>> Yeah.  But I see sstep.c already mixes those two at will (or if there
>>> is a distinction, I'm not seeing it :-) )
>>
>> Yeah OK. In practice they're equivalent, if CONFIG_PPC64=y then the
>> kernel is built 64-bit and therefore __powerpc64__ is defined.
>>
>> But I agree it's a mess, we should use CONFIG_PPC64 exclusively unless
>> there's some reason not to (which I don't think there ever is).
>>
>>>> I thought the reason some are #ifdef'ed is that some are 64-bit only.
>>>> ie. bpermd is 64-bit only ?
>>>
>>> 64-bit only, in what way?  It's not clear what the rules are.
>>
>> Instructions that have "d" in the name? :P
>>
>>> It's not instructions that can only run in 64-bit mode.
>>> It's not instructions that only give a usable result with 64-bit regs
>>> implemented.
>>> It's not instructions only implemented on 64-bit CPUs.
>>
>> I think it's trying to be that ^
>>
>> If you build a 32-bit kernel then instructions that are only defined on
>> 64-bit CPUs should be treated as illegal, so the easiest way to achieve
>> that is to #ifdef off the code for those instructions.
>
> I'll fixup this up to use the xor implementation, and change the
> series to use CONFIG_PPC64 for the ifdef.

Thanks.

In terms of the actual algorithms, we want to use something reasonably
efficient, but don't sweat too much on the performance. The overhead of
the emulation is in the exception we took to get there. So readable and
obviously correct source is the main goal.

cheers


More information about the Linuxppc-dev mailing list