Re: [newbie alert] How does FreeBSD support hardware?

On Tue, 30 Nov 2021 05:19:35 +0100
"mayuresh@kathe.in" <mayuresh@kathe.in> wrote:

> I am confused about how FreeBSD supports every new generation of
> processors, e.g. from Intel. I guess, FreeBSD uses GNU "gas" to which
> Intel actively contributes code to keep that assembler updated for every
> iteration (model) of Intel's processors. So when the kernel and userland
> are built, Clang/LLVM uses "gas" to generate binaries to support newer
> instructions as provided by the processor. But, what is the magic within
> FreeBSD that makes the whole system be aware of changed instructions such

	The magic (to the extent that it is used) is in the compiler which
can generate code optimised with newer instructions. However the FreeBSD
binaries you download will be built to a lowest common denominator and for
the most part only use those instructions that are on all supported
processors.

	There are exceptions to this some programs are written to query
the processor and select different versions of subroutines depending on
what's available - mplayer/mencoder does this. Similar things are done
with encryption libraries and DRI for which the kernel exposes an API
which may use software or be accelerated depending on what the kernel finds
when it probes the CPU. For this someone had to write the code for each
version and the code to select which version to use. The decisions are made
at startup and used to set pointers to one version or another in a table of
entry points.

> that all the code (which need not necessarily be updated throughout with
> every new processor iteration) gets optimized well? How would FreeBSD
> applications know of changes like AVX2 and SIMD and utilize them without

	If you build from source you can set compile options to specify
building for a specific version of the CPU (--march and --mcpu IIRC) and
then get as much as the compiler knows about used.

	Ultimately there's no magic, some programmer has to do the work of
deciding how to use the instructions. The result of that work is usually
embedded in the compiler or used to provide multiple versions of routines
to be selected dynamically or at compile time.

	Heavily optimising the OS code is usually a waste of time because
the system should be spending most of the time running application code and
much of the time the system performance is dominated by I/O not CPU so even
optimising application code to the CPU is often not worthwhile. Only when
the code is CPU bound (video transcoding, crypto-currency mining ...) does
it make a lot of difference.

-- 
Steve O'Hara-Smith <steve@sohara.org>