Re: [PATCH] [RFC] x86/cpu: rework instruction set selection

["H. Peter Anvin" <hpa@xxxxxxxxx>]

On April 27, 2025 6:24:59 AM PDT, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>On Sat, Apr 26, 2025, at 21:09, Ingo Molnar wrote:
>> * Arnd Bergmann <arnd@xxxxxxxx> 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 
>>> alongside them for years, and some of the 586-class Vortex86 products 
>>> are still commercially available.
>>
>> Very few (if any) of the commercially available products will run 
>> modern 6.16+ kernels, right?
>
>No, at least not in absolute numbers. As far as I can tell, the RDC
>SoC family is the only one that is still around, after Quark, Geode
>and Eden were all discontinued around 2019.
>
>There are multiple known RDC licensees (DM&P/Vortex86, xlichip) and
>probably a few more with custom chips. They lag behind Intel and AMD
>by about one patent expiration time, and maybe a decade behind Arm
>SoCs, so they only just arrived at quad-core SMP, LPDDR4, and SSSE3
>instructions and have announced upcoming 64-bit chips.
>
>They do have super-long support cycles, and there are a few markets
>that absolutely require kernel updates for many years, so I would
>still consider the 586-class embedded chips more relevant for future
>kernels than 30 year old PCs, and the 686-class embedded chips
>more relevant than 20 year old laptops.
>
>> Note that the real danger the 32-bit x86 kernel is going to be facing 
>> in 2-5 years is total removal due to lack of development interest, but 
>> I think we can support 686+ reasonably far into the future, and can 
>> keep it tested reasonably - while covering like 99%+ of the currently 
>> available 32-bit-only x86 products on the market. The fewer variants, 
>> the better.
>
>I agree that this is the endgame for x86-32 and that eventually
>the while thing will be remove, and every simplification helps, but
>I still don't think that removing 586 earlier helps enough to
>outweigh the cost here.
>
>The situation is similar on 32-bit Arm, where we currently support
>armv4, armv4t, armv5, armv6, armv6k, armv7, armv7ve and armv8-aarch32.
>Removing armv3 a few years ago helped a lot, removing the extremely
>rare armv6 will help as well, but there is little value in dropping
>CPU support for v4 and v4t as long as v5 is there, or v6k and v7
>as long as we have v7ve and v8-aarch32. My guess would be that we
>can remove armv4/v4t/v5 at the same time as i586/i686 and
>some other 32-bit targets, followed by armv7/v7ve/v8-aarch32
>much later.
>
>       Arnd

"Commercially available" doesn't mean "binary distribution." There is a whold 
world beyond the desktop distros.

These kinds of systems run embedded stacks that are at least in part compiled 
by the appliance vendor to allow for higher configurability.