Rewrite much of the 486->686 default code generation section. This mostly
improves the wording, but also fleshes out some of the examples given and
provides more examples. Minor typos also corrected.
@ -329,12 +329,28 @@ This section covers changes to the FreeBSD Ports Collection, package infrastruct
Starting with FreeBSD-13.0, the default `CPUTYPE` for the i386 architecture will change from `486` to `686`.
This means that, by default, binaries produced will require a 686-class CPU, including but not limited to binaries provided by the FreeBSD Release Engineering team. FreeBSD 13.0 will continue to support older CPUs, however users needing this functionality will need to build their own releases for official support.
As the embedded market is the primary user of cores based on i486 and i565, end-user impact is expected to be minimal. Both server and desktop machines based on these CPU types are generally over 20 years old and have been retired or are too resource poor to make FreeBSD 13.0 an attractive upgrade.
There were several factors taken into account for this change. For example, i486 does not have 64-bit atomics, and while they can be emulated in the kernel, they cannot be emulated in the userland. Additionally, the 32-bit amd64 libraries have been i686 since their inception.
As the majority of 32-bit testing is done by developers using the lib32 libraries on 64-bit hardware with the `COMPAT_FREEBSD32` option in the kernel, this change ensures better coverage and user experience. This also aligns with what the majority of Linux(R) distributions have been doing for quite some time.
This means that, by default, binaries produced will require a 686-class CPU, including but not limited to binaries provided by the FreeBSD Release Engineering team.
The FreeBSD 13.0 code base will continue to support older CPUs.
Users needing this functionality, however, will need to build their own releases to obtain this support.
As the embedded market is the primary user of cores based on i486 and i586, end-user impact is expected to be minimal.
Most embedded systems have custom builds already.
Althought some minor adjust will be necessary, it will be on par with the effort required to move between major versions.
Server and desktop machines based on these CPU types are generally over 20 years old.
Most have been retired or are too resource poor to make FreeBSD 13.0 an attractive upgrade.
There were several factors taken into account for this change.
Most applications need 64-bit atomics for proper operation.
While those operations can be emulated in the kernel on i486, they cannot be emulated in the userland.
Updating the default allows compiler generated code to select the right atomics in those cases, allow better optimizations and produce better error messages when necessary.
The older library and/or include file approaches are much less optimal in resulting code and diagnostics.
Current compiler technology produces better, faster, and/or smaller binaries for i686 than for i486.
Several bugs in compiler support for i486 code generation attest to its lessor use in the wider ecosystem.
In the wider ecosystem, i686 has been the default for many years so has received more testing and more optimization.
Finally, the 32-bit amd64 libraries have been i686 since their inception.
These factors strongly suggest that a i686 default will provide such an improved enough user experience to offset the minor pain for those few users of the older technology.
As the majority of 32-bit testing is done by developers using the lib32 libraries on 64-bit hardware with the `COMPAT_FREEBSD32` option in the kernel, this change ensures better coverage and user experience.
This also aligns with what the majority of Linux(R) distributions have been doing for quite some time.
This is expected to be the final bump of the default `CPUTYPE` in i386.
Warner Losh
3 years ago