The future of 32-bit Linux [LWN.net]

The future of 32-bit Linux

Posted Dec 5, 2020 8:42 UTC (Sat) by ewen (subscriber, #4772)
Parent article: The future of 32-bit Linux

For what it’s worth, 32-bit RISC-V Linux is being used on FPGA based RISC-V builds (often VexRisc as RV32I). Particularly LiteX (Enjoy Digital) has done a lot of work on RV32 Linux in a FPGA, as boards with enough RAM to run Linux are fairly common, but FPGAs with open tools big enough to fit RV64 designs and other things are less common/much more expensive.

But I do agree it seems likely that in a few years there’ll only be a few 32 bit architectures still supported in Linux. 32 bit ARM and 32 but RISC-V seem the most relevant.

Ewen

PS: for ASIC/Silicon designs aimed to run Linux, most of those have gone direct to RV64. And I agree the only silicon designs for RV32I are aimed at microcontroller/embedded controller replacements rather than Linux at present. But it wouldn’t surprise me to see RV32I in things like NAS or routers running Linux, in future.

to post comments

The future of 32-bit Linux

Posted Dec 8, 2020 4:13 UTC (Tue) by mithro (subscriber, #50469) [Link] (3 responses)

The key thing for FPGAs is that wider bit widths dramatically reduce the frequency a soft processor is able to achieve. A 64bit adder is usually more than twice as slow as a 32bit adder, routing a 64bit bus is more than twice as hard as routing a 32bit bus, etc.

This is very different to ASICs on modern process nodes where the extra cost of going to 64bit is generally dwarfed by the investment needed and general lifetime of the part.

If there is a resurgence of ASICs which want to run Linux on older process nodes (like maybe 130nm due to a new fully open source ecosystem - https://www.youtube.com/watch?v=EczW2IWdnOM - and a free shuttle program - https://efabless.com/open_shuttle_program ;-) then the trend might change. When your cache sizes are small due to silicon limitations, those 64bit wide values start to seem more problematic.

The future of 32-bit Linux

Posted Dec 8, 2020 8:52 UTC (Tue) by arnd (subscriber, #8866) [Link] (1 responses)

Right, when dealing with a small RV32I core comparable to a 1990s ARM7 or i386, going to 64 bits is out of the question. Once you get to bigger FPGAs and add in M, A, F, D, C and V extensions, as well go to larger caches, TLBs, and pipelines, the core is more like a Cortex-A7 or an early Intel Atom, so going to 64 bit is only a small step.

For the smallest cores, you'd also leave out the MMU and run some other OS that correspond to a modern take on µCLinux-2.0, but the interesting spot to watch is everything in between -- how big does an FPGA core have to be to make Linux-5.x the OS of choice without getting so big that you want to go straight to 64-bit Linux, and how long does it take before that niche disappears.

The future of 32-bit Linux

Posted Dec 8, 2020 17:54 UTC (Tue) by mithro (subscriber, #50469) [Link]

Due to plentify block ram in most modern FPGAs, an MMU implementation on an FPGA can actually be pretty cheap.

At the moment a <$100 USD FPGA dev board with <1 gigabytes RAM can be purchased that a 32bit Linux + MMU is *significantly* smaller and faster than 64bit. Due to the newer FPGAs mostly been focused on the datacenter use case and thus in the >$500 USD per FPGA IC, I don't see this changing for at least another 5ish years.

The future of 32-bit Linux

Posted Dec 8, 2020 19:44 UTC (Tue) by geert (subscriber, #98403) [Link]

Can't you mitigate this partly by adding one or two pipeline stages, to split 64-bit additions and address calculations in two 32-bit operations?