Future direction of x86 builds
Nick Lowe
nick.lowe at gmail.com
Sun May 10 03:38:27 PDT 2026
x86-64 Target Split
I think there is a similar opportunity to make the x86-64 targets
clearer as well.
My suggested split would be:
1) x86/x86-64-v1
Legacy-compatible 64-bit target.
Suggested compiler baseline:
-march=x86-64
Boot method:
BIOS only
Intended hardware:
older AMD64 systems
older embedded x86-64 appliances
early 64-bit systems without UEFI
hardware that is still 64-bit capable but does not meet x86-64-v2
This should remain the compatibility target for older 64-bit x86 hardware.
The naming should make the ISA baseline explicit: this is the x86-64-v1 build.
---
2) x86/x86-64-v2
Modern 64-bit target.
Suggested compiler baseline:
-march=x86-64-v2
Boot method:
UEFI only
Intended hardware:
modern x86-64 systems
most UEFI-capable appliances
newer embedded x86-64 platforms
hardware where x86-64-v2 is a reasonable baseline expectation
This would be the preferred/default modern 64-bit x86 target.
Tying x86-64-v2 to UEFI makes the split much cleaner: older BIOS-only
systems stay on x86-64-v1, while the UEFI build can move to a more
modern ISA baseline.
---
The current distinction between BIOS and UEFI images is already partly
a hardware-generation distinction. Making the compiler baseline
reflect that would make the target contract clearer.
In practice:
BIOS x86-64 remains conservative and broadly compatible.
UEFI x86-64 becomes the modern baseline.
The target names describe the actual ISA expectation.
Users do not need to infer CPU requirements from vague names like generic.
This also avoids raising the baseline for all x86-64 users at once.
Older 64-bit systems still have a maintained build, but newer UEFI
systems get a more appropriate compiler target.
---
Future x86-64-v3
There may eventually be a case for an x86/x86-64-v3 target, but I
don't think that is the right step yet.
x86-64-v3 would imply AVX/AVX2-era assumptions and would exclude a
much larger set of still-useful hardware. For OpenWrt, the benefit
probably does not justify the additional build target today.
More information about the openwrt-devel
mailing list