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

On 11/29/21 11:38 PM, Steve O'Hara-Smith wrote:
> 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
> 

Steve, thanks a lot from all of us, newbies, for all the instructive 
stuff you write below!

Valeri

> 	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.
> 

-- 
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++