LWN: Comments on "32-Bit x86 support in Fedora" https://lwn.net/Articles/728207/ This is a special feed containing comments posted to the individual LWN article titled "32-Bit x86 support in Fedora". en-us Thu, 23 Oct 2025 13:52:48 +0000 Thu, 23 Oct 2025 13:52:48 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net I wish! But no. https://lwn.net/Articles/729081/ https://lwn.net/Articles/729081/ felix.s <div class="FormattedComment"> You mean, catch SIGILL/the illegal opcode exception, emulate the opcode in software and resume execution? I've actually tried doing just that: it didn't work. The reason is that some SSE2 opcodes are encoded as REP-prefixed SSE opcodes, and my Pentium III simply ignored the REP prefix instead of generating an illegal opcode exception.<br> <p> So instead of crashing with SIGILL, SSE2 programs started crashing with SIGSEGV because %ebp was being randomly thrashed...<br> <p> </div> Thu, 27 Jul 2017 19:52:05 +0000 [Completely OT] 32-Bit x86 support in Fedora https://lwn.net/Articles/728549/ https://lwn.net/Articles/728549/ dskoll <p>I think you meant <i>exacerbated</i> rather than <i>exasperated</i>, but your way is much funnier and more picturesque! :) Fri, 21 Jul 2017 18:38:11 +0000 32-Bit x86 support in Fedora https://lwn.net/Articles/728456/ https://lwn.net/Articles/728456/ smoogen <div class="FormattedComment"> The default download is 64 bit with lines on the right for 32 bit downloads. The reason is that i386 downloads have been dropping in requests with ~95% of the users for F25 using x86_64. <br> </div> Thu, 20 Jul 2017 19:25:57 +0000 32bit have a couple of advantages for VMs https://lwn.net/Articles/728446/ https://lwn.net/Articles/728446/ excors <div class="FormattedComment"> I suspect a kernel-based emulator would be around three orders of magnitude slower than hardware - e.g. an SSE2 instruction can perform 16 8-bit additions in a third of a clock cycle (on modern CPUs), or 4 float additions in half a cycle, whereas trapping into the kernel and performing all those operations serially and saving the results in an emulated register file in memory is going to take forever. Even a non-performance-intensive application that only spends 10% of its time dealing with floats could run 100x slower with emulation.<br> <p> For users, an application running 100x slower may be nearly as unusable as an application crashing with an "instruction not supported" error, and is much harder for the application's developer to debug from a bug report. In both cases the developer would probably just switch their compiler flags from SSE2 to x87 once they recognise the problem.<br> <p> Applications that do lots of number crunching and want to support a wide range of users will already provide both x87 and SSE2 code paths, and select one based on CPU capabilities, so the emulation won't improve compatibility there (and might confuse the capability detection code).<br> <p> The only case where emulation would really help is code that uses a non-zero but tiny amount of SSE2, so it would improve compatibility and nobody would care about the performance cost, and that doesn't sound common enough to justify a substantial effort.<br> <p> There is an Intel Software Development Emulator &lt;<a href="https://software.intel.com/en-us/articles/intel-software-development-emulator">https://software.intel.com/en-us/articles/intel-software-...</a>&gt; that emulates recent SIMD instructions etc, but that's for developers to test them before hardware support is available, it's not intended for users. (It seems to do a sort of JIT translation that can replace certain instructions with calls into the emulator, which is much faster than reacting to illegal instruction exceptions.)<br> </div> Thu, 20 Jul 2017 17:21:01 +0000 32bit have a couple of advantages for VMs https://lwn.net/Articles/728441/ https://lwn.net/Articles/728441/ epa <div class="FormattedComment"> I just wondered if perhaps Intel (or AMD) in the past had written such an SSE2 floating point emulator and released it. Chipmakers do occasionally write emulators for their current or upcoming products. The existence of the emulator doesn't reduce future sales since it is inevitably slower than real silicon.<br> </div> Thu, 20 Jul 2017 15:00:24 +0000 32-Bit x86 support in Fedora https://lwn.net/Articles/728440/ https://lwn.net/Articles/728440/ smoogen <div class="FormattedComment"> Fedora is still committed to working on arm 32 bit as long as people are coming to the table to fix problems. I have not started looking at the number of i686 bugs but what people had said to me was that they were generally limitations of the x86 platform that are exasperated by the lack of space in 32 bit. [They still 'exist' in 64 bits but are shoved out into petabyte memory ranges versus gigabyte ranges.] <br> <p> In the end, I am mostly trying to get people to say they are really going to work on things or not. This is a similar problem to the python-ideas article. My goal is to see if people who want i686 to continue have enough time to make it continue. If they don't then it would be good to help them transition to either an OS that has a larger clump of people who do.<br> </div> Thu, 20 Jul 2017 14:50:56 +0000 32bit have a couple of advantages for VMs https://lwn.net/Articles/728400/ https://lwn.net/Articles/728400/ zdzichu <div class="FormattedComment"> You can do anything in software. But man hour cost for coding such emulation would greatly exceed the cost of losing i686 support. Anyway SSE2 emulation would be throw-away code. People don't want to create DoA things.<br> No one volunteered to take care of 32 bit bugs in distribution, and taking care of bugs is much much simple than coding SSE2 emulation.<br> </div> Thu, 20 Jul 2017 11:17:56 +0000 32bit have a couple of advantages for VMs https://lwn.net/Articles/728398/ https://lwn.net/Articles/728398/ farnz <p>The same issue applies here as to that old x87 emulator - it's considerably slower than "real" SSE2, and would almost certainly be considerably slower than just using the x87 path. Plus, it would still be under-tested; instead of the x87 path being under-tested in the apps that use it, you'd now have a slow and under-tested emulator. Thu, 20 Jul 2017 10:32:54 +0000 32-Bit x86 support in Fedora https://lwn.net/Articles/728396/ https://lwn.net/Articles/728396/ marcH <div class="FormattedComment"> <font class="QuotedText">&gt; In addition, several pointed to Atom-based systems that are 32-bit, some of which are still being sold (mostly in the embedded space).</font><br> <p> Just checked and Fedora seems to support 32bit ARMv7 (4Go is a decent amount of RAM for an average "embedded" system)<br> <p> Curious about the (vague) number of i686 bugs at stake here and their typical nature.<br> <p> (and yes: too lazy to click on every link and more in the article :-)<br> </div> Thu, 20 Jul 2017 10:24:51 +0000 32bit have a couple of advantages for VMs https://lwn.net/Articles/728395/ https://lwn.net/Articles/728395/ epa <div class="FormattedComment"> Can you trap SSE2 instructions and emulate them with x87 (or MMX or SSE) instructions on older systems? Or is that idea a non-starter? I know Linux used to have an x87 floating point emulator for 486SX and similar systems.<br> </div> Thu, 20 Jul 2017 10:13:53 +0000 32-Bit x86 support in Fedora https://lwn.net/Articles/728388/ https://lwn.net/Articles/728388/ pr1268 <p>I was going to ask the same question, but then I realized that other 32-bit <em>NON</em>-x86 architectures may continue to be supported (and for whom SSE2 [or lack thereof] is inapplicable). But, 32-bit <tt>time_t</tt> may still be around for some time to come.</p> <p>Is that indeed the case?</p> Thu, 20 Jul 2017 09:06:52 +0000 32-Bit x86 support in Fedora https://lwn.net/Articles/728385/ https://lwn.net/Articles/728385/ sorokin As distributions are dropping i686, does it mean that year 2038 problem is not a problem now?<br/> <br/> Also I'm glad that <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323">legendary GCC bug 323</a> isn't a bug now. Strictly speaking deprecating i686 wasn't necessary for this, requiring cpu to support SSE (Pentium III) would be enough.<br/> Thu, 20 Jul 2017 08:51:34 +0000 32bit have a couple of advantages for VMs https://lwn.net/Articles/728382/ https://lwn.net/Articles/728382/ farnz <p>SSE2 is a compulsory part of AMD64, for both long mode (64-bit kernel) and legacy mode (32-bit or 16-bit kernel). Real i686-class machines are not guaranteed to have SSE2 - the Pentium III and 32-bit AMD Athlon chips don't, for example; thus, if Fedora drops support for i686, SSE2 becomes a baseline feature for 32-bit userspace (as the kernel is 64-bit). At the moment, 32-bit userspace can't assume SSE or SSE2 support, which means that it has to use the (less tested, nowadays) x87 FP support, instead of the (much saner) SSE2 FP support. <p>Fedora could take a baby step in this direction if people stepped up to the plate to support it, and change its i686 to require SSE2; however, that's a decision for an x86-32 SIG to make once it's up and running (as that'll be the people doing the work). Thu, 20 Jul 2017 08:37:10 +0000 32bit have a couple of advantages for VMs https://lwn.net/Articles/728374/ https://lwn.net/Articles/728374/ gmatht <div class="FormattedComment"> VirtualBox won't let you virtualize AMD64 images without support from BIOS. Saving memory can be important for VMs, and i686 is still better supported than the newer x32 ABI. Nevertheless, I've switched to AMD64 everywhere.<br> <p> It is not clear how dropping i686 would help much with SSE2. Presumably we could enable SSE2 on the AMD64 bit arch and leave i686 alone. Or is the consideration people who run i686 code on 64bit kernels?<br> </div> Thu, 20 Jul 2017 07:01:57 +0000 32-Bit x86 support in Fedora https://lwn.net/Articles/728367/ https://lwn.net/Articles/728367/ chder <div class="FormattedComment"> Seems like they need more of this kind of call for help on the 32 bit version's download page... unless they already do.<br> <p> I don't see any such appeal on <a href="https://getfedora.org/en/workstation/download/">https://getfedora.org/en/workstation/download/</a> but it may be detecting my arch and not bothering since it is defaulting to giving me the 64 bit version anyways.<br> </div> Thu, 20 Jul 2017 03:43:23 +0000 Y2038 (was: 32-Bit x86 support in Fedora) https://lwn.net/Articles/728363/ https://lwn.net/Articles/728363/ cesarb <div class="FormattedComment"> <font class="QuotedText">&gt; Quite a few Linux distributions are eliminating 32-bit builds, so Fedora is hardly alone if it takes that route.</font><br> <p> If this happens, I won't be surprised if 20 years later this is seen as having been the correct choice.<br> </div> Thu, 20 Jul 2017 01:04:40 +0000 32-Bit x86 support in Fedora https://lwn.net/Articles/728359/ https://lwn.net/Articles/728359/ karkhaz <div class="FormattedComment"> FWIW, Arch Linux recently deprecated support for i686; it will no longer be supported from this November. Arch doesn't support lots of architectures like Debian or Fedora does, either---x86_64 is the only other platform with official support.<br> <p> <a href="https://www.archlinux.org/news/phasing-out-i686-support/">https://www.archlinux.org/news/phasing-out-i686-support/</a><br> </div> Wed, 19 Jul 2017 22:00:54 +0000 32-Bit x86 support in Fedora https://lwn.net/Articles/728345/ https://lwn.net/Articles/728345/ smoogen <div class="FormattedComment"> Thank you for the coverage on this. <br> </div> Wed, 19 Jul 2017 20:13:32 +0000