[PATCH v3 4/5] powerpc/lib/sstep: Add prty instruction emulation
mpe at ellerman.id.au
Thu Jul 27 11:26:51 AEST 2017
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
> 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.
More information about the Linuxppc-dev