This page shows all the different copy functions configured when I586_CPU is enabled. There are no entries for I686_CPU in there, which tells me that all the optimisations are enabled for I585_CPU and not for I686_CPU. Haven't looked through any of the other pages in that list just yet.

I think it just means i586 and newer CPUS?, not i586 only, cause every new CPU fully supports older CPU's (backwards compatible), that is.... you need at least i585 to be able to execute (assemble) that parts of code

One would have to do a series of micro- and macro-benchmarks to determine the exact benefits of enabling I586_CPU, I686_CPU, and I586_CPU with I686_CPU, on various CPUs, to see what the optimal setting is. There were a bunch of benchmarks done back in 2005/2006 with various encryption algorithms that showed enabling I586_CPU (with I686_CPU) on P3 CPUs gave better performance than just I686_CPU (due to all the bzero, bcopy, mmx copy, and other memory tricks that are enabled with I586_CPU but not with I686_CPU).

Whether or not that still holds true today, with Athlon64s, Core/Core2, Opterons, etc, I don't know. But there hasn't been anything since then saying it hurts things.

This page shows all the different copy functions configured when I586_CPU is enabled. There are no entries for I686_CPU in there, which tells me that all the optimisations are enabled for I585_CPU and not for I686_CPU.

But it is enabled only if cpu actually have npx (DEV_NPX defined), 686 CPU do not have that coprocessor. (ony 486DX CPU, and systems with 387 or 487SX coprocessors)
This npx(4) man page may shed more light.
I think if it is possible on some of such CPUs to build kernel without I586_CPU and than npx routines would be emulated - slower.

But it is enabled only if cpu actually have npx (DEV_NPX defined), 686 CPU do not have that coprocessor. (ony 486DX CPU, and systems with 387 or 487SX coprocessors)
This npx(4) man page may shed more light.
I think if it is possible on some of such CPUs to build kernel without I586_CPU and than npx routines would be emulated - slower.

All x86 processors, modern ones anyway, have a math coproccessor.. and it's a requirement of OpenBSD at least.

In newer processors, it's a part of the actual CPU.. in the 486/386 era, it was an optional upgrade.

I have a few systems without math coprocessor, NetBSD runs fine on them.. as it has a FPU emulator. (Loss of precision though.).

I'm not aware of FreeBSD has a FPU emulator or not, but in the OpenBSD world.. it was dropped after the switch to the ELF format, nobody wanted to port it over.

I'm a guest here, in OpenBSD.. CPU optimizations go unrecommended, and considering the negligible amount of class specific code, why not keep them all defined? IMHO.

But it is enabled only if cpu actually have npx (DEV_NPX defined), 686 CPU do not have that coprocessor. (ony 486DX CPU, and systems with 387 or 487SX coprocessors)
This npx(4) man page may shed more light.
I think if it is possible on some of such CPUs to build kernel without I586_CPU and than npx routines would be emulated - slower.

npx(4) is a *required* device on 32-bit FreeBSD (i386). You can't (easily) build a kernel without it. It's part of the DEFAULTS file that gets automatically pulled into every kernel build (on FreeBSD 6+, it's part of GENERIC on FreeBSD 5-).

Reading the npx man page shows that the optimisations are only enabled if the I586_CPU option is enabled in the kernel config, which matches what the source shows. Which supports what I've been saying. The only way to get these optimisations is to have I586_CPU enabled in your kernel config.

Now, whether or not those optimisations are still beneficial is up for debate.