share/mk/bsd.cpu.mk: add F16C feature for i386 and amd64 architectures

As discussed in bug 278417, some ports require the F16C instruction set
to compile, but there is no way yet to detect whether the currently
chosen CPUTYPE supports this feature.

Add the feature to the MACHINE_CPU variable, for each processor that
supports it. The list of processors was extracted from clang 18's -dM
output, filtered on the __F16C__ define.

PR: 278417
Reviewed by: brooks, emaste
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D44848

share/mk/bsd.cpu.mk: Add AMD Zen 4 for x86

Main difference between older Zen variants is that this supports AVX-512

Reviewed by: imp (previous version), emaste
Approved by: emaste
Differential Revision: https://reviews.freebsd.org/D41331

Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

share/mk/bsd.cpu.mk: drop -mno-powerpc64

Clang doesn't have -mno-powerpc64.

Differential revision: https://reviews.freebsd.org/D40589
Approved by: jhibbits

share/mk/bsd.cpu.mk: handle the default case when CPUTYPE is not specified on powerpc*

Approved by: imp
Differential Revision: https://reviews.freebsd.org/D40576

share/mk/bsd.cpu.mk: add AltiVec / VSX to powerpc*'s MACHINE_CPU

MFC after: 3 days
Approved by: jhibbits
Differential revision: https://reviews.freebsd.org/D39240

Remove a few more references to riscv64sf.

Fixes: 1ca12bd927d7 Remove the riscv64sf architecture.

bsd.cpu.mk: Simplify armv[67] support

Drop a clause that's no longer relevant to v4/v5. Drop support for
softfloat for v[45]. Simplify soft float expression by assuming we're
always either armv6 or armv7.

Sponsored by: Netflix
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D38584

bsd.cpu.mk: Introduce MACHINE_ABI

MACHINE_ABI is a list of properties of the ABI used for MACHINE_ARCH.
It should be used in place of long conditionals on MACHINE_ARCH where
practical.

The following properties are indicated with one of the follow values:

Byte order: big-endian, little-endian
Floating point ABI: soft-float, hard-float
Size of long (size_t, etc): long32, long64
Pointer type: ptr32, ptr64
Size of time_t: time32, time64

For example, i386 targets will be:
MACHINE_ABI= big-endian hard-float long32 ptr32 time32

Reviewed by: imp
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D36421

bsd.cpu.mk: Remove mips support

Remove the tweaks to the compiler, as well as additional command line
args to get the proper endian, word size and floating style.

Sponsored by: Netflix

bsd.cpu.mk: Minor formatting for armv6 vs armv7

Separate out the arch/cpu options for armv6 from the armv7 ones. This is
less confusing.

Sponsored by: Netflix

bsd.cpu.mk: add support for x86-64-v[234] levels as CPUTYPE

These are supported in LLVM 12 and GCC 11:

https://github.com/llvm/llvm-project/commit/012dd42e027e
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=324bec558e95584e8c1997575ae9d75978af59f1

Differential Revision: https://reviews.freebsd.org/D29150

bsd.cpu.mk: Correct MACHINE_CPU for Intel Alder Lake

Apparently Intel Alder Lake lacks AVX-512 instructions.

Fixes: 09e7341c5ea4 "Catch up with Clang 12"

Catch up with Clang 12.

Add "znver3" for AMD and "alderlake" and "sapphirerapids" for Intel.

[PowerPC64LE] Set up powerpc.powerpc64le architecture

This is the initial set up for PowerPC64LE.

The current plan is for this arch to remain experimental for FreeBSD 13.

This started as a weekend learning project for me and kinda snowballed from
there.

(More to follow momentarily.)

Reviewed by: imp (earlier version), emaste
Sponsored by: Tag1 Consulting, Inc.
Differential Revision: https://reviews.freebsd.org/D26399

When CPUTYPE is an architecture name use -march

Allow architecture names to be passed in to the build system via CPUTYPE.
This allows the user to use values such as armv8.1-a or armv8-a+crc as
the CPUTYPE.

Sponsored by: Innovate UK

powerpc: --secure-plt only needs to pass to ld.bfd, not ld.lld

ld.lld only supports secure-plt for powerpc, so no need to pass the argument
in.

[PowerPC] Switch powerpc and powerpcspe to lld

Now that LLD 10 is out, and required patches have landed, we are now ready
to finally switch away from the ancient in-tree ld.bfd.

Special thanks to Fangrui Song for many hours of work on getting the
32-bit powerpc lld ready for prime-time.

Reviewed by: emaste (earlier revision), jhibbits
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D24111

Add "tigerlake" CPUTYPE for x86 to catch up with Clang 10.0.

Remove sparc64 specific buid-system hacks

Remove all the sparc64 hacks and tweaks to the build system. We don't
need them anymore.

Catch up with Clang 9.0.

Add note to remind me there are three choices for arm32 floating point.

hard use floating point hardware, pass registers to functions in
floating point registers.
softfp use floating point hardware, but pass registers to functions
in integer registers.
soft do floating point calcuations without using floating point
hardware. Pass arguments in integer registers.

FreeBSD 11 and newer assumes hard. 10 and earlier assumed softfp. We have no
real support, at the moment, for soft. It's untested, though, if softfp still
works.

Add a note here since this is a whack-a-doodle combination relative to all other
platforms.

softfp is likely to go away in the future because it was retained for people
using FreeBSD 10 + armv6 needing to transition more slowly from softfp -> hard
than the project. It likely is no longer needed, and may be getting in the
way of people needing 'soft' support.

Add -mno-relax to CFLAGS in bsd.prog/lib.mk instead of bsd.cpu.mk.

bsd.cpu.mk is included by bsd.init.mk before bsd.linker.mk, so it
was always setting the flag since LINKER_FEATURES wasn't defined.

Reported by: mhorne
Reviewed by: imp, mhorne
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D23076

[PowerPC64] Use ld.bfd to build LIB32 and STAND - when using llvm

Summary:
This patch is to support ongoing work for replacing "GCC/BFD" by "CLANG/LLD" on
target PowerPC64 [1], by proposing a way to specify and/or locate a secondary
ld.bfd linker.
This is necessary as LLD currently doesn't support PowerPC 32 bits, so we keep
using BFD for the 32 bit stuff on PowePC64(LIB32 compatibility and
STAND/slof/loader.)

- creates LD_BFD variable pointing to ld.bfd
- use LD_BFD as linker for LIB32/compat
- Default behavior for other platforms aren't changed.

[1] https://wiki.freebsd.org/powerpc/llvm-elfv2

Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D20261

Add a new "riscv-relaxations" linker feature.

When the linker doesn't have this feature, add -mno-relax to CFLAGS
on RISC-V.

Define the feature for ld.bfd, but not lld. If lld gains relaxation
support in a newer version, we can enable it for those versions of lld
in bsd.linker.mk.

Reviewed by: mhorne
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D22659

Consolidate powerpcspe CFLAGS

Don't depend on CPUTYPE to define powerpcspe CFLAGS, they should be set
unconditionally. This reduces duplication. Also, set some CFLAGS as
gcc-only, because clang's SPE support always uses the SPE ABI, it's not an
optional feature.

powerpcspe: use -mspe instead of -mspe=yes to enable SPE

-mspe=yes/no was deprecated even before GCC 4.2.1 in favor of
-mspe/-mno-spe. Clang only supports -mspe/-mno-spe.

Make setting mips endian and ABI less verbose.

Allow ABI to be over ridden to allow (with other changes) programs to be
built targeting ABIs other than the default. This is used in CheriBSD.

Reviewed by: imp
Obtained from: CheriBSD
MFC after: 1 week
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D21001

powerpc: Transition to Secure-PLT, like most other OSs (Toolchain part)

Summary:
Toolchain follow-up to r349350. LLVM patches will be submitted upstream for
9.0 as well.

The bsd.cpu.mk change is required because GNU ld assumes BSS-PLT if it
cannot determine for certain that it needs Secure-PLT, and some binaries do
not compile in such a way to make it know to use Secure-PLT.

Reviewed By: nwhitehorn, bdragon, pfg
Differential Revision: https://reviews.freebsd.org/D20598

Catch up with Clang 8.0.

Catch up with Clang 7.0.

MFC after: 3 days

Correct the CPU target for powerpcspe

The MPC8540 is actually e500v1, which doesn't have double-precision floating
point support. The 8548 does, so use that as the CPU target.

MFC after: 2 weeks

Enable 'C'-compressed ISA extension.

This was disabled recently due to lack of support in KDB disassembler
and DTrace FBT provider. Support for 'C'-extension to both of these was
added, so we can now enable 'C'-extension.

This reduces size of the kernel important for low-end embedded devices,
and saves cache footprint for high perfomance machines.

Approved by: re (kib)
Sponsored by: DARPA, AFRL

Revert r336773: it removed too much.

r336773 removed all things xscale. However, some things xscale are
really armv5. Revert that entirely. A more modest removal will follow.

Noticed by: andrew@

Remove xscale support

The OLD XSCALE stuff hasn't been useful in a while. The original
committer (cognet@) was the only one that had boards for it. He's
blessed this removal. Newer XSCALE (GUMSTIX) is for hardware that's
quite old. After discussion on arm@, it was clear there was no support
for keeping it.

Differential Review: https://reviews.freebsd.org/D16313

Disable 'C'-compressed ISA extension.

It works excellent, but KDB disassembler and DTrace FBT provider for
RISC-V do lack support for it. They currently handle 4-byte instructions
only, while C-compressed ISA extension introduces 2-byte instructions
freely mixing them together.

So disable it for now.

Reviewed by: markj@
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D16436

Remove special cases for armeb in the build.

Differential Revision: https://reviews.freebsd.org/D16257

Don't specify the desired march/mabi for RISC-V in ACFLAGS.

ACFLAGS is only used in addition to CFLAGS, so setting the options in
both was redundant. However, ACFLAGS is added to the command line
after CFLAGS, so the settings from ACFLAGS were applied for assembly
files in kernel modules after the kernel-specific march/abi in CFLAGS.
As a result, the hard-float ACFLAGS in bsd.cpu.mk was overriding the
soft-float CFLAGS.gcc in sys/conf/kern.mk. In particular,
dtrace_asm.o was compiled as hard-float and the linker refused to link
dtrace.ko since its object files contained a mix of hard and soft
float.

Reviewed by: br
Sponsored by: DARPA / AFRL
Differential Revision: https://reviews.freebsd.org/D16054

Don't use TARGET_ARCH in this file, use MACHINE_ARCH instead.

TARGET_ARCH is not defined when building ports/packages.

Sponsored by: DARPA, AFRL

Set correct float abi (float abi double) for hard-float build, so
__riscv_float_abi_double macro will be defined by compiler.

The options are:
o lp64 __riscv_float_abi_soft
o lp64f __riscv_float_abi_single
o lp64d __riscv_float_abi_double

Sponsored by: DARPA, AFRL

Catch up with Clang 6.0.

MFC after: 3 days

Add -mno-avx2 for clang as well as -mno-avx. We don't want either of
them when asking for no SIMD.

Reviewed by: emaste@
Sponsored by: Netflix

Support armv7 builds for userland

Make armv7 as a new MACHINE_ARCH.

Copy all the places we do armv6 and add armv7 as basically an
alias. clang appears to generate code for armv7 by default. armv7 hard
float isn't supported by the the in-tree gcc, so it hasn't been
updated to have a new default.

Support armv7 as a new valid MACHINE_ARCH (and by extension
TARGET_ARCH).

Add armv7 to the universe build.

Differential Revision: https://reviews.freebsd.org/D12010

We don't use ARM_ARCH_6 in the tree, and haven't for a long long
time. Remove it from here. As far as I could tell, nothing in ports
use it (either __ARM_ARCH or __ARM_ARCH_6__ is used in all the
apatches). We do have a define for _ARM_ARCH_6, but it's mostly unused
(and will remain, since it isn't in this file).

Delete trailing whitespace

MFC after: 1 month

Support for v1.10 (latest) of RISC-V privilege specification.

New version is not compatible on supervisor mode with v1.9.1
(previous version).

Highlights:
o BBL (Berkeley Boot Loader) provides no initial page tables
anymore allowing us to choose VM, to build page tables manually
and enable MMU in S-mode.
o SBI interface changed.
o GENERIC kernel.
FDT is now chosen standard for RISC-V hardware description.
DTB is now provided by Spike (golden model simulator). This
allows us to introduce GENERIC kernel. However, description
for console and timer devices is not provided in DTB, so move
these devices temporary to nexus bus.
o Supervisor can't access userspace by default. Solution is to
set SUM (permit Supervisor User Memory access) bit in sstatus
register.
o Compressed extension is now turned on by default.
o External GCC 7.1 compiler used.
o _gp renamed to __global_pointer$
o Compiler -march= string is now in use allowing us to choose
required extensions (compressed, FPU, atomic, etc).

Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D11800

Explicitly set the desired MIPS ABI in toolchain flags.

Specifically, set '-mabi=XX' in AFLAGS, CFLAGS, and LDFLAGS. This permits
building MIPS worlds and binaries with a toolchain whose default output
does not match the desired TARGET_ARCH.

_LDFLAGS (which is used with LD instead of with CC) required an update as
LD does not accept the -mabi flags (so they must be stripped from LDFLAGS
when generating _LDFLAGS). For bare uses of LD (rather than linking via
CC), the desired ABI must be set by setting an explicit linker emulation
as done in r316514 for kernels and kernel modules.

Reviewed by: imp
Sponsored by: DARPA / AFRL
Differential Revision: https://reviews.freebsd.org/D10085

Don't set the MIPS endianness flags in both ACFLAGS and CFLAGS.

This should no longer be necessary after r316620 as all places that
use ACFLAGS should already be using CFLAGS.

Reviewed by: imp
Sponsored by: DARPA / AFRL
Differential Revision: https://reviews.freebsd.org/D10085

Catch up with Clang 4.0.0.

Add full softfloat and hardfloat support for RISC-V.

Hardfloat is now default (use riscv64sf as TARGET_ARCH
for softfloat).

Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D8529

Set endianness and floating point flags explicitly for MIPS targets

The tree can be build with an external toolchain that will not
necessarily default to desired settings, so we have to specify
the required flags explicitly to force the required compilation
mode.

Reviewed by: adrian, br
Sponsored by: https://reviews.freebsd.org/D8505

Use proper MACHINE_ARCH.

This fixes ports on mips after r308130.

o Add support for long double.
o Add support for latest RISC-V GNU toolchain.

Sponsored by: DARPA, AFRL
Sponsored by: HEIF5

Add full softfloat and hardfloat support for MIPS.

This adds new target architectures for hardfloat:
mipselhf mipshf mips64elhf mips64hf.

Tested in QEMU only.

Sponsored by: DARPA, AFRL
Sponsored by: HEIF5
Differential Revision: https://reviews.freebsd.org/D8376

Create a new MACHINE_ARCH for Freescale PowerPC e500v2

Summary:
The Freescale e500v2 PowerPC core does not use a standard FPU.
Instead, it uses a Signal Processing Engine (SPE)--a DSP-style vector processor
unit, which doubles as a FPU. The PowerPC SPE ABI is incompatible with the
stock powerpc ABI, so a new MACHINE_ARCH was created to deal with this.
Additionaly, the SPE opcodes overlap with Altivec, so these are mutually
exclusive. Taking advantage of this fact, a new file, powerpc/booke/spe.c, was
created with the same function set as in powerpc/powerpc/altivec.c, so it
becomes effectively a drop-in replacement. setjmp/longjmp were modified to save
the upper 32-bits of the now-64-bit GPRs (upper 32-bits are only accessible by
the SPE).

Note: This does _not_ support the SPE in the e500v1, as the e500v1 SPE does not
support double-precision floating point.

Also, without a new MACHINE_ARCH it would be impossible to provide binary
packages which utilize the SPE.

Additionally, no work has been done to support ports, work is needed for this.
This also means no newer gcc can yet be used. However, gcc's powerpc support
has been refactored which would make adding a powerpcspe-freebsd target very
easy.

Test Plan:
This was lightly tested on a RouterBoard RB800 and an AmigaOne A1222
(P1022-based) board, compiled against the new ABI. Base system utilities
(/bin/sh, /bin/ls, etc) still function appropriately, the system is able to boot
multiuser.

Reviewed By: bdrewery, imp
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D5683

Revert r303911 "Remove extra -msoft-float flags settings."
This was not properly tested.

Remove extra -msoft-float flags settings.
This helps to build firmware modules.

Sponsored by: DARPA, AFRL
Sponsored by: HEIF5

Set the soft-float flag for assembly code as well.
This fixes compilation with GCC 6.1.

Sponsored by: DARPA, AFRL

Make armv6 hard float abi by default. Kill armv6hf.
Allow CPUTYPE=soft to build the current soft-float abi libraries.
Add UPDATING entry to announce this.

Approved by: re@ (gjb)

share: minor spelling fixes.

Mostly comments but these tend to be user-visible.

MFC after: 2 weeks

Support simple soft floating point abi for CPUTYPE in arm. Complex
types to follow.

Start support for the RISC-V 64-bit architecture developed by UC Berkeley.

RISC-V is a new ISA designed to support computer research and education, and
is now become a standard open architecture for industry implementations.

This is a minimal set of changes required to run 'make kernel-toolchain'
using external (GNU) toolchain.

The FreeBSD/RISC-V project home: https://wiki.freebsd.org/riscv.

Reviewed by: andrew, bdrewery, emaste, imp
Sponsored by: DARPA, AFRL
Sponsored by: HEIF5
Differential Revision: https://reviews.freebsd.org/D4445

Handle CPUTYPE=armv[4567]* better. gcc expects those to be either
-march=foo or -mcpu=generic-foo. Catch the armvX* case and pass
the right args for it.

Add aarch64 support to CPUTYPE

Add arm CPUTYPE values typically used on FreeBSD.

Fix missing endif.

Fix mips CPUTYPE so that we can pass it through to gcc.
Keep old CPUTYPEs around for compatibility. Also include
a list of typical values for FreeBSD.

# Split out from other changes in D4155

Differential Revision: https://reviews.freebsd.org/D4155

Fix URL for powerpc cpu options. Remove reference to ia64 options as
no longer relevant.

After consultations with the arm community, don't define softfp for
armv6. It's too ambiguous. We do use the softfp ABI for the moment on
armv6, but we allow floating point register use (and the compilers
will generate it). This is too ambiguous to use it as a decider for
which algorithms to use on the platform. Err on the side of caution
and not define it.

Submitted by: ian@
Reviewed by: andrew@

Add softfp to MACHINE_CPU more often when we're compiling for soft
float targets. It is added for booke on powerpc and all arm with hf in
the string. Also add arm to all arm builds and armv6 to armv6 and
newer builds.

PR: 202641

We need to add the soft float to the CFLAGS always, not just when
NO_CPUCFLAGS is not defined since it is part of the ABI as we've
defined it, not just a nice optimization.

Disable SSE in libthr

Clang emits SSE instructions on amd64 in the common path of
pthread_mutex_unlock. If the thread does not otherwise use SSE,
this usage incurs a context-switch of the FPU/SSE state, which
reduces the performance of multiple real-world applications by a
non-trivial amount (3-5% in one application).

Instead of this change, I experimented with eagerly switching the
FPU state at context-switch time. This did not help. Most of the
cost seems to be in the read/write of memory--as kib@ stated--and
not in the #NM handling. I tested on machines with and without
XSAVEOPT.

One counter-argument to this change is that most applications already
use SIMD, and the number of applications and amount of SIMD usage
are only increasing. This is absolutely true. I agree that--in
general and in principle--this change is in the wrong direction.
However, there are applications that do not use enough SSE to offset
the extra context-switch cost. SSE does not provide a clear benefit
in the current libthr code with the current compiler, but it does
provide a clear loss in some cases. Therefore, disabling SSE in
libthr is a non-loss for most, and a gain for some.

I refrained from disabling SSE in libc--as was suggested--because
I can't make the above argument for libc. It provides a wide variety
of code; each case should be analyzed separately.

https://lists.freebsd.org/pipermail/freebsd-current/2015-March/055193.html

Suggestions from: dim, jmg, rpaulo
Approved by: kib (mentor)
MFC after: 2 weeks
Sponsored by: Dell Inc.

Set MACHINE_CPU to arm64 when building for arm64. This is needed by the
ports tree as they check this value in a number of ports.

PR: 201259
Sponsored by: ABT Systems Ltd

Sort the cpu architectures by name rather than a combination of
alphabetical order and appending new architectures to the end of the list.

Obtained from: ABT Systems Ltd
Sponsored by: The FreeBSD Foundation

Catch up with Clang 3.6.0.

For armv6 builds, add -mfloat-abi=softfp. This tells the compiler it can
use floating point hardware instructions (because all armv6/7 systems we
support have fp hardware), but it passes args using a soft-float compatible
ABI. This should give noticible performance improvement (but not as much
as using the armv6hf arch).

Set the correct architecture when targeting ARMv7

MFC after: 1 Week
Sponsored by: ABT Systems Ltd

Support CXXFLAGS.${MACHINE_ARCH} as well as CFLAGS. This allows different
C++ options for toolchain versus target when cross-building.

Remove ia64.

This includes:
o All directories named *ia64*
o All files named *ia64*
o All ia64-specific code guarded by __ia64__
o All ia64-specific makefile logic
o Mention of ia64 in comments and documentation

This excludes:
o Everything under contrib/
o Everything under crypto/
o sys/xen/interface
o sys/sys/elf_common.h

Discussed at: BSDcan

Add new CPUTYPEs supported by Clang 3.4, i.e., AMD Steamroller (bdver3) and
Intel Silvermont (slm) processors.

Add a way to apply CFLAGS only when building the given architecture. This
is useful primarily on a system used for cross-building, when you have a
set of flags to apply to the TARGET_ARCH being cross-built but don't want
those settings applied to building the cross-tools or other components that
run on the build host machine.

Add a new CPUTYPE supported by Clang 3.3 for AMD Jaguar processors (btver2).

Nuke ARM_WANT_TP_ADDRESS, it's not used anymore.
Don't force -march=armv6 for Cortex A, as we want at least armv6k. The
compiler default is good enough.

Fix typos in the previous commit.

Tidy up bsd.cpu.mk for X86 CPUs:

- Do not limit recent processors to "prescott" class for i386 target. There
is no reason for this hack because clang is default now. On top of that, it
will only grow indefinitely over time.
- Add more CPUTYPEs, i.e., "athlon-fx", "core-avx2", "atom", "penryn", and
"yonah". Note "penryn" and "yonah" are intentionally undocumented because
they are not supported by gcc and marked deprecated by clang.
- Add more CPUTYPE aliases, i.e., "barcelona" (-> amdfam10), "westmere" and
"nehalem" (-> corei7). Note these are intentionally undocumented because
they are not supported by (base) gcc and/or clang. However, LLVM (backend)
seems to "know" the differences. Most likely, they were deprecated with
other vendor code names and clang did not bother implementing them at all.
- Add i686 to MACHINE_CPU for "c3-2" (VIA Nehemiah). Both gcc & clang treat
it like an i686-class processor.
- Add IDT "winchip2" and "winchip-c6" for completeness (undocumented).
- Order processors per make.conf example, i.e., CPU vendors and models.
- Tidy up make.conf example, i.e., remove "by gcc" (because we have aliases)
and remove "prescott" from AMD64 architecture (because it is not correct).

Remove fictitious support for 80386-class CPUs from bsd.cpu.mk and make(1).
It was removed from head more than 8 years ago (see r137784 and r137785).

Reviewed by: imp, delphij, dim

Add x86 CPUs supported by clang on head.

Reviewed by: arch (silence)
X-MFC: r242624

Merging of projects/armv6, part 3

r238211:
Support TARGET_ARCH=armv6 and TARGET_ARCH=armv6eb

This adds a new TARGET_ARCH for building on ARM
processors that support the ARMv6K multiprocessor
extensions. In particular, these processors have
better support for TLS and mutex operations.

This mostly touches a lot of Makefiles to extend
existing patterns for inferring CPUARCH from ARCH.
It also configures:
* GCC to default to arm1176jz-s
* GCC to predefine __FreeBSD_ARCH_armv6__
* gas to default to ARM_ARCH_V6K
* uname -p to return 'armv6'
* make so that MACHINE_ARCH defaults to 'armv6'
It also changes a number of headers to use
the compiler __ARM_ARCH_XXX__ macros to configure
processor-specific support routines.

Submitted by: Tim Kientzle <kientzle@freebsd.org>

Remove support for the Intel C Compiler from the build infrastructure.
This support has not worked for several years, and is not likely to work
again, unless Intel decides to release a native FreeBSD version of their
compiler. ;)

Add ssse3 capability for CPUTYPE=core2 to MACHINE_CPU in bsd.cpu.mk

MFC after: 2 weeks

Add AMD Geode CPU type to bsd.cpu.mk and examples/etc/make.conf
For CPUTYPE=core2 use -march=core2

PR: gnu/155308
MFC after: 2 weeks

Add opteron-sse3, athlon64-sse3 and k8-sse3 cpu types to bsd.cpu.mk.
- add "sse3" to MACHINE_CPU for the new cpu types
- for i386, default to CPUTYPE=prescott for the new cpu types

PR: gnu/154906
Discussed with: kib, kan, dim
MFC after: 2 weeks

- Add CPUTYPE support for sparc64. The net result is that it's now possible
to let the compiler optimize for the famility of UltraSPARC-III CPUs as the
default already was to optimize for UltraSPARC-I/II and generating generic
64-bit V9 is mainly for reference purposes. At least for SPARC64-V CPUs
code optimized for UltraSPARC-I/II still is the most performant one.
Thanks go to Michael Moll for testing SPARC64-V.
- Move a booke MACHINE_CPU bit into the right section.

This case is actually powerpc specific, and doesn't apply to powerpc64.

Submitted by: nathanw@

Complete the integration of tbemd branch into head.

TARGET_BIG_ENDIAN is now completely dead, except where it was
originally supposed to be used (internally in the toolchain building).

TARGET_ARCH has changed in three cases:
(1) Little endian mips has changed to mipsel.
(2) Big endian mips has changed to mipseb.
(3) Big endian arm has changed to armeb.

Some additional changes are needed to make 'make universe' work on arm
and mips after this change, so those are commented out for now.

UPDATING information will be forthcoming. Any remaining rough edges
will be hammered out in -current.

A new jail(8) with a configuration file, to replace the work currently done
by /etc/rc.d/jail.

Prefer MACHINE_CPUARCH to MACHINE_ARCH unless there's a good reason...

Now that we default to the proper endian, we don't need these for mips

Minor modifications to know what to do with powerpc64.

MFC r206973:

When CPUTYPE is defined to any value, on amd64 platform "mmx" is
available through MACHINE_CPU, indicating the CPU supports that
feature, as done by revision 138685.

This changeset adds "mmx" into the default amd64 MACHINE_CPU list
when no CPUTYPE is specified to provide consistent behavior.

PR: amd64/145593
Submitted by: mm

When CPUTYPE is defined to any value, on amd64 platform "mmx" is
available through MACHINE_CPU, indicating the CPU supports that
feature, as done by revision 138685.

This changeset adds "mmx" into the default amd64 MACHINE_CPU list
when no CPUTYPE is specified to provide consistent behavior.

PR: amd64/145593
Submitted by: mm
MFC after: 2 weeks

Create the altix project branch. The altix project will add support
for the SGI Altix 350 to FreeBSD/ia64. The hardware used for porting
is a two-module system, consisting of a base compute module and a
CPU expansion module. SGI's NUMAFlex architecture can be an excellent
platform to test CPU affinity and NUMA-aware features in FreeBSD.

-mabi-calls and -msoft-float aren't needed either

Submitted by: jmallet@

-mno-dsp hasn't been required for a while now.

Kernel module support for mips.

Reviewed by: gonzo

Tested by: Alexandr Rybalko (ray@dlink.ua)

- Remove -mno-dsp from CFLAGS. MIPS DSP ASE is off by default
now (as it should be)

Add support for 64-bit PowerPC CPUs operating in the 64-bit bridge mode
provided, for example, on the PowerPC 970 (G5), as well as on related CPUs
like the POWER3 and POWER4.

This also adds support for various built-in hardware found on Apple G5
hardware (e.g. the IBM CPC925 northbridge).

Reviewed by: grehan

Explicitly disable generation of Altivec instructions in the kernel on PowerPC,
and add support to allow users to set their CPUTYPE in make.conf.

- Import the HEAD csup code which is the basis for the cvsmode work.

Fix links to online gcc docs.

Reported by: Andre Guibert de Bruet <andy@siliconlandmark.com>
MFC after: 1 day

Add support for MACHINE_ARCH == mips, plus a few generic CPU types that
will be supported in the forth coming FreeBSD/mips port.

Connect MPC85XX to the PowerPC build.

The kernel config file is KERNCONF=MPC85XX, so the usual procedure applies:

1. make buildworld TARGET_ARCH=powerpc
2. make buildkernel TARGET_ARCH=powerpc TARGET_CPUTYPE=e500 KERNCONF=MPC85XX

This default config uses kernel-level FPU emulation. For the soft-float world
approach:

1. make buildworld TARGET_ARCH=powerpc TARGET_CPUTYPE=e500
2. disable FPU_EMU option in sys/powerpc/conf/MPC85XX
3. make buildkernel TARGET_ARCH=powerpc TARGET_CPUTYPE=e500 KERNCONF=MPC85XX

Approved by: cognet (mentor)
MFp4: e500

Add a 'c7' CPUTYPE for VIA C7 CPUs that is 'c3-2' with the addition of
i686, sse2, and sse3.

MFC after: 1 week

Backout rev 1.62, and revert to use -march=armv5te -D__XSCALE__ instead
of -mcpu=xscale for XScale.
gcc still has issues with -mcpu=xscale, and now crashes while building
systat.

Reported by: sam
MFC After: 3 days

GCC doesn't segfault anymore while building world with -mcpu=xscale, so use it.

"If I only had a brain..."

MFC after: 3 weeks

Correct errors in previous commit. I didn't realize that ${CPUTYPE} is
passed unmodified to gcc. Therefore, "prescott" should be used for Prescott,
Nocona, Core and Core 2 CPUs when building 32-bit code, and "nocona" should
be used for Prescott, Nocona and Core 2 CPUs when building 64-bit code.

MFC after: 3 weeks

On i386, make "prescott" an alias for "nocona" (instead of the other way
around), and introduce "core", along with the alias "core2". All of these
enable SSE3.

On amd64, add "core2" (enables SSE3).

MFC after: 3 weeks

Use TARGET_BIG_ENDIAN instead of ARM_BIG_ENDIAN

Remove alpha left-overs.

Revert previous commit. Pre-Nehemiah C3 CPUs do have 3DNow!; it doesn't
show up in dmesg because identcpu.c only looks for it on Intel and AMD
processors.

I don't know where I got the idea that the VIA C3 has 3DNow!; it doesn't.
It does have MMX (though MMX support is reputed to be incomplete in early
generations), and later generations have SSE.

MFC after: 2 weeks

Grr we also need to set -mbig-endian to LDFLAGS. Now I can build a
big-endian arm world.

Remove ALPHA optimization pointer for gcc flags.
Add ARM optimization pointer for gcc flags.

Oops LDFLAGS can be used to invoke gcc, so directly add -EB to {LD}.

Honor ARM_BIG_ENDIAN by adding -mbig-endian to CFLAGS and -EB to LDFLAGS if
it is defined.

Add CPUTYPE support for Via C3 and C3-2 processors.

MFC after: 2 weeks

Add a MACHINE_CPU entry for "ev67".

Use -march=armv5te for Xscale.

Rev 1.44 was a little over-zealous for FreeBSD/AMD64, trim.

No need to add I386_CPU to CFLAGS here for 80386 systems as they are no
longer supported.

Define "I386_CPU" if CPUTYPE is 'i386'. Userland bits can check for "I386_CPU"
to determine if they should select code paths suitable for the 80386 CPU.

Suggested by: ru

Embellish the AMD64 sections a little. Including supporting 'nocona'.

+ Simplify by treating the standard x86 CPU names as the CPUTYPE vs.
treating them as an alias. Treat the shorthand versions as aliases.
+ Separate the x86 GCC CPU CFLAGS from the ICC CFLAGS. This greatly
simplifies the GCC section. It also makes it more clear which CPU's
have the same ICC CPU CFLAGS.
+ Remove redundancy in the alpha section.
+ Add forgotten ICC CPU CFLAGS for the mobile Intel CPU's added in rev. 1.42.

Add support for Pentium M, Pentium 3M and Pentium 4M.

PR: i386/72340
Submitted by: Rong-En Fan <rafan@infor.org>
MFC after: 2 weeks

Add CPUCFLAGS for the strongarm and xscale CPUs.

Add more aliases for common CPUTYPE spellings

Consistently list _CPUCFLAGS.

Define MACHINE_CPU for arm.

Add ${CPUTYPE} support for crusoe processors (cribbed from Linux kernel
settings). Pretend that a crusoe is an i686 which doesn't like alignment
padding.

Add a reference to the ia64 options to gcc. While here, sort the list.

Fix some style bugs in previous commit.
Fix 'broken' ifdefs.
icc does not support profiling yet so remove unfinished code which was
supposed to help.

Submitted by: netchild (original version)
Reviewed by: ru

This are the build infrastructure changes to allow to use the
Intel C/C++ compiler (lang/icc) to build the kernel.

The icc CPUTYPE CFLAGS use icc v7 syntax, icc v8 moans about them, but
doesn't abort. They also produce CPU specific code (new instructions
of the CPU, not only CPU specific scheduling), so if you get coredumps
with signal 4 (SIGILL, illegal instruction) you've used the wrong
CPUTYPE.

Incarnations of this patch survive gcc compiles and my make universe.
I use it on my desktop.

To use it update share/mk, add
/usr/local/intel/compiler70/ia32/bin (icc v7, works)
or
/usr/local/intel_cc_80/bin (icc v8, doesn't work)
to your PATH, make sure you have a new kernel compile directory
(e.g. MYKERNEL_icc) and run
CFLAGS="-O2 -ip" CC=icc make depend
CFLAGS="-O2 -ip" CC=icc make
in it.

Don't compile with -ipo, the build infrastructure uses ld directly to
link the kernel and the modules, but -ipo needs the link step to be
performed with Intel's linker.

Problems with icc v8:
- panic: npx0 cannot be emulated on an SMP system
- UP: first start of /bin/sh results in a FP exception

Parts of this commit contains suggestions or submissions from
Marius Strobl <marius@alchemy.franken.de>.

Reviewed by: silence on -arch
Submitted by: netchild

Fixed indentation of conditionals.

Submitted by: Rostislav Krasny <rosti_bsd@yahoo.com>

Fixed some style bugs (long lines).

Drop -mcpu=pentiumpro from the default CPU flags for i386 as it doesn't
perform better than the default setting for most i386 CPUs.

Requested by: bde

Keep up with sys/conf/ changes.

Since -march=pentium4 is supposed to be fixed with GCC 3.3, and
since people have been reporting success with it, re-enable the
pentium4 optimization.

Change -march=pentium4 to -march=pentium3 when CPUTYPE==p4, because gcc 3.2 is
known to produce broken code with -march=pentium4. Add a note explaining this.
This should be removed when we update to gcc 3.3 or the bug is otherwise fixed.

Approved by: re

s/x86[-_]64/amd64/ for MACHINE_ARCH and MACHINE_CPU .ifdefs.

Noticed by: ru
Approved by: re (amd64-specific low risk stuff)

Add CPUTYPE support for "athlon-tbird", as GCC makes the distinction.

PR: 50801
Submitted by: Glenn Johnson <glennpj@charter.net>

Default the userland to 486 capabilities.

Globally use -mieee in /usr/src for Alpha.

Reduce "code duplication" for AMD CPU's.

Whitespace-only indention fixups for revision 1.20. This lets the 1.20
diff actually be readable.

Oops, fix userland _CPUCFLAGS. Move adding of _CPUCFLAGS to bottom of
file after end of empty CPUTYPE else clause.

For the default case of CPUTYPE not being set, don't define CPUTYPE to the
lowest value in order to get the right MACHINE_CPU values since setting
CPUTYPE can result in problems later in the buildkernel case. Instead,
set MACHINE_CPU directly and leave CPUTYPE alone.

Tested by: mbr

Add support for the AMD x86-64 Hammer platform.

Add support for ev67 and ev45 CPUTYPEs (new in gcc3)

Update to use all the new CPU optimizations of GCC3.

Reviewed by: kris

TARGET_CPUTYPE should exist solely in Makefile.inc1, similar to
TARGET_ARCH and TARGET. This is problematic when one has the =
(unconditional) type of assigment for CPUTYPE in /etc/make.conf.
(This would override what was set on the command line to "make
buildworld".)

Add a (horrible) kludge to Makefile.inc1 to check the type of
assignment for CPUTYPE (only for those who attempts to set it to
a different value). Fix an example make.conf. Fix the kernel's
build-tools target (aicasm only at the moment) to catch up with
bsd.cpu.mk,v 1.15 (BOOTSTRAPPING replaced with NO_CPU_CFLAGS in
Makefile.inc1's BMAKE).

Reviewed by: jhb

- Define NO_CPU_CFLAGS during BMAKE and TMAKE (and thus XMAKE) so that
bsd.cpu.mk doesn't have to worry about compilers other than the current
version.
- Allow TARGET_CPUTYPE to override CPUTYPE in bsd.cpu.mk.
- Treat an empty CPUTYPE the same as an undefined CPUTYPE.
- For buildworld, buildkernel, etc., define TARGET_CPUTYPE to CPUTYPE for
native builds and define it to be empty for cross-builds.
TARGET_CPUTYPE is only defined if it is not already defined via the
commandline or environment.

- Fixup whitespace after previous commit.
- To minimize whitespace changes, remove a test that didn't define
_CPUCFLAGS if both NO_CPU_CFLAGS and NO_CPU_COPTFLAGS were defined
since it is redundant (we don't use _CPUCFLAGS if those are defined).

If there is not a CPUTYPE defined by default, then allow for _CPUCFLAGS
to tune for more advanced processors while still supporting the minimum
processor in an architecture. We can do this with the '-mtune=' option
to gcc for alpha, sparc64, and powerpc and with the mis-named '-mcpu='
option for i386.

This defaults to tuning i386 builds for i686 machines though not using
any instructions that aren't found on an 80386. For alpha it defaults
to tuning for an EV5.

Approved by: peter
Peril sensitive sunglasses borrowed from: peter

In gcc 3.1 Pentium/MMX now has its own -march=XXX option.

Bootstrapping aid for those with Athlon upgrading from gcc 2.95.x.

Prodded by: gordon

Default Alpha compiles to ev5.
EV5 binaries will run on EV4[5], but the timing assumptions do pessimize
running on EV4[5].

Tested by: ticso

Add pointers to GCC's allowable values for -march, and restore structure
of rev 1.7 until someone can sit down and think thru all the GCC 3.1
related changes.

With GCC 3.1, we can now treat AMD Athlon and an Athlon.

Submitted by: Steven G. Kargl <kargl@troutmask.apl.washington.edu>

Add the beginnings of Sparc64 support.

Optimize for i486 better (-m486 is just another deprecated
synonym for -mcpu=i486).

PR: i386/37212
Submitted by: Matthias Andree <matthias.andree@web.de>
MFC after: 3 days

Pentium II's do not support SSE, that came in with the PIII

Submitted by: sf

Use CPUTYPE to add appropriate compiler flags to COPTFLAGS for kernel
builds. This may be disabled using the NO_CPU_COPTFLAGS variable.

Reviewed by: arch

AMD K6/K6-2/Duron/Athlon CPUs support MMX too.

Missed by: kris

Add definitions and support for the AMD k6-2, Pentium MMX (i586/MMX),
and Pentium II, III and IV processors (p2, p3, p4), as well as 'mmx' and
'3dnow' MACHINE_CPU tags as appropriate. In the near future this will
be used to control various ports which have MMX/3dNow optimizations,
instead of the ad-hoc methods currently used.

Reviewed by: peter

Overhaul the MACHINE_CPU behaviour:

* Rip out MACHINE_CPU stuff from sys.mk and include a new <bsd.cpu.mk>
after we pull in /etc/make.conf. We need to do it afterwards so we can
react to the user setting of the:

* CPUTYPE variable, which contains the CPU type which the user wants to
optimize for. For example, if you want your binaries to only run on an
i686-class machine (or higher), set this to i686. If you want to support
running binaries on a variety of CPU generations, set this to the lowest
common denominator. Supported values are listed in make.conf.

* bsd.cpu.mk does the expansion of CPUTYPE into MACHINE_CPU using the
(hopefully) correct unordered list of CPU types which should be used on
that CPU. For example, an AMD k6 CPU wants any of the following:
k6 k5 i586 i486 i386
This is still an unordered list so the client makefile logic is simple -
client makefiles need to test for the various elements of the set in
decreasing order of priority using ${MACHINE_CPU:M<foo>}, as before.
The various MACHINE_CPU lists are believed to be correct, but should be
checked.

* If NO_CPU_CFLAGS is not defined, add relevant gcc compiler optimization
settings by default (e.g. -karch=k6 for CPUTYPE=k6, etc). Release
builders and developers of third-party software need to make sure not to
enable CPU-specific optimization when generating code intended to be
portable. We probably need to move to an /etc/world.conf to allow the
optimization stuff to be applied separately to world/kernel and external
compilations, but it's not any worse a problem than it was before.

* Add coverage for the ia64/itanium MACHINE_ARCH/CPUTYPE.

* Add CPUTYPE support for all of the CPU types supported by FreeBSD and gcc
(only i386, alpha and ia64 first, since those are the minimally-working
ports. Other architecture porters, please feel free to add the relevant
gunk for your platform).

Reviewed by: jhb, obrien