On April 27, 2025 6:24:59 AM PDT, Arnd Bergmann wrote:
>On Sat, Apr 26, 2025, at 21:09, Ingo Molnar wrote:
>> * Arnd Bergmann wrote:
>>
>>> CMOV is missing not just on old Socket 5/7 CPUs (Pentium MMX, AMD K6,
>>> Cyrix MII) but also newer embedded Via C3, Geode GX and
>>> Vortex86DX/MX/EX/DX2.
On April 27, 2025 12:34:46 PM PDT, Linus Torvalds
wrote:
>On Sun, 27 Apr 2025 at 12:17, Andrew Cooper wrote:
>>
>> ffs/fls are commonly found inside loops where x is the loop condition
>> too. Therefore, using statically_true() to provide a form without the
>> zero compatibility turns out to be
On Sun, 27 Apr 2025 at 12:17, Andrew Cooper wrote:
>
> ffs/fls are commonly found inside loops where x is the loop condition
> too. Therefore, using statically_true() to provide a form without the
> zero compatibility turns out to be a win.
We already have the version without the zero capability
On 26/04/2025 8:55 pm, Linus Torvalds wrote:
> So I think that manual cmov pattern for x86-32 should be replaced with
>
> bool zero;
>
> asm("bsfl %[in],%[out]"
> CC_SET(z)
> : CC_OUT(z) (zero),
> [out]"=r" (r)
> : [in] "rm" (x));
>
On Sat, Apr 26, 2025, at 21:09, Ingo Molnar wrote:
> * Arnd Bergmann wrote:
>
>> CMOV is missing not just on old Socket 5/7 CPUs (Pentium MMX, AMD K6,
>> Cyrix MII) but also newer embedded Via C3, Geode GX and
>> Vortex86DX/MX/EX/DX2. The replacement Nehemiah (2003), GeodeLX (2005)
>> and Vorte
* H. Peter Anvin wrote:
> The undefined zero case applies to family < 6 as far as I know... the
> same platforms which don't have cmov...
So, technically, these are family 5 CPUs with CMOV support, if
Kconfig.cpu can be believed:
MGEODE_LX
MCRUSOE
Right?
Ingo
* Linus Torvalds wrote:
> On Sat, 26 Apr 2025 at 11:59, Arnd Bergmann wrote:
> >
> > Right. With the current set of features, CMOV is almost the
> > same as 686. My reasoning was that support for CMOV has a
> > very clear definition, with the instruction either being
> > available or not.
>
>
On April 26, 2025 11:55:50 AM PDT, Ingo Molnar wrote:
>
>* H. Peter Anvin wrote:
>
>> Dropping CMOV would mean dropping P5 support.
>
>Yeah, I think we should make the cutoff at the 686 level. Is there any
>strong reason not to do that? Stable kernels will still exist for a
>very long time for
On April 26, 2025 12:55:13 PM PDT, Linus Torvalds
wrote:
>On Sat, 26 Apr 2025 at 12:24, Linus Torvalds
> wrote:
>>
>> (And yes, one use in a x86 header file that is pretty questionable
>> too: I think the reason for the cmov is actually i486-only behavior
>> and we could probably unify the 32-bit
On April 26, 2025 12:55:13 PM PDT, Linus Torvalds
wrote:
>On Sat, 26 Apr 2025 at 12:24, Linus Torvalds
> wrote:
>>
>> (And yes, one use in a x86 header file that is pretty questionable
>> too: I think the reason for the cmov is actually i486-only behavior
>> and we could probably unify the 32-bit
On Sat, Apr 26, 2025, at 11:08, Ingo Molnar wrote:
> * Arnd Bergmann wrote:
>
> While the simplification is nice on its face, this looks messy:
>
>>
>> config X86_PAE
>> bool "PAE (Physical Address Extension) Support"
>> -depends on X86_32 && X86_HAVE_PAE
>> +depends on X86_32 && X
On Sat, 26 Apr 2025 at 11:59, Arnd Bergmann wrote:
>
> Right. With the current set of features, CMOV is almost the
> same as 686. My reasoning was that support for CMOV has a
> very clear definition, with the instruction either being
> available or not.
Yeah, I don't think there's any reason to m
On Sat, 26 Apr 2025 at 12:24, Linus Torvalds
wrote:
>
> (And yes, one use in a x86 header file that is pretty questionable
> too: I think the reason for the cmov is actually i486-only behavior
> and we could probably unify the 32-bit and 64-bit implementation)
Actually, what we *should* do is to
* Arnd Bergmann wrote:
> CMOV is missing not just on old Socket 5/7 CPUs (Pentium MMX, AMD K6,
> Cyrix MII) but also newer embedded Via C3, Geode GX and
> Vortex86DX/MX/EX/DX2. The replacement Nehemiah (2003), GeodeLX (2005)
> and Vortex86DX3/EX2 (2015!) have CMOV, but the old ones were sold
* H. Peter Anvin wrote:
> Dropping CMOV would mean dropping P5 support.
Yeah, I think we should make the cutoff at the 686 level. Is there any
strong reason not to do that? Stable kernels will still exist for a
very long time for ancient boards.
Ingo
On April 26, 2025 2:08:17 AM PDT, Ingo Molnar wrote:
>
>* Arnd Bergmann wrote:
>
>> From: Arnd Bergmann
>>
>> With cx8 and tsc being mandatory features, the only important
>> architectural features are now cmov and pae.
>>
>> Change the large list of target CPUs to no longer pick the instructi
* Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> With cx8 and tsc being mandatory features, the only important
> architectural features are now cmov and pae.
>
> Change the large list of target CPUs to no longer pick the instruction set
> itself but only the mtune= optimization level and in-
On April 25, 2025 9:13:31 AM PDT, Arnd Bergmann wrote:
>On Fri, Apr 25, 2025, at 17:34, H. Peter Anvin wrote:
>> On April 25, 2025 7:15:15 AM PDT, Arnd Bergmann wrote:
>>
>> I really don't like testing an unrelated feature (CMOV for PAE);
>
>How about a new symbol with the opposite polarity, e.g
On Fri, Apr 25, 2025, at 17:34, H. Peter Anvin wrote:
> On April 25, 2025 7:15:15 AM PDT, Arnd Bergmann wrote:
>
> I really don't like testing an unrelated feature (CMOV for PAE);
How about a new symbol with the opposite polarity, e.g. CONFIG_CPU_586?
In that case, X86_HAVE_PAE and X86_CMOV coul
On April 25, 2025 7:15:15 AM PDT, Arnd Bergmann wrote:
>From: Arnd Bergmann
>
>With cx8 and tsc being mandatory features, the only important
>architectural features are now cmov and pae.
>
>Change the large list of target CPUs to no longer pick the instruction set
>itself but only the mtune= opti
From: Arnd Bergmann
With cx8 and tsc being mandatory features, the only important
architectural features are now cmov and pae.
Change the large list of target CPUs to no longer pick the instruction set
itself but only the mtune= optimization level and in-kernel optimizations
that remain compatib
21 matches
Mail list logo
