ARCH(7)

📦
version 15.1 · 2 versions
, in freebsd 15.1, nixpkgs unstable

✨ arch(7) — Architecture-specific details ✨

okay so this is arch(7) from the Miscellaneous Information Manual, and it's literally your cheat sheet for the differences between CPU architectures and platforms supported by FreeBSD. 🫶

💖 DESCRIPTION 💖

Differences between CPU architectures and platforms supported by FreeBSD. Slay, that's the whole vibe. 🦋

🌸 Introduction 🌸

This document is a quick reference of key ABI details of FreeBSD architecture ports. For full details consult the processor-specific ABI supplement documentation. iykyk, this is the short version. ✨

If not explicitly mentioned, sizes are in bytes. The architecture details in this document apply to FreeBSD 13.0 and later, unless otherwise noted.

FreeBSD uses a flat address space. Variables of types unsigned long, uintptr_t, and size_t and pointers all have the same representation.

In order to maximize compatibility with future pointer integrity mechanisms, manipulations of pointers as integers should be performed via uintptr_t or intptr_t and no other types. In particular, long and ptrdiff_t should be avoided. bestie, do not do pointer-integer gymnastics with long or ptrdiff_t, okay? 😭

On some architectures, e.g., AIM variants of powerpc64, the kernel uses a separate address space. On other architectures, kernel and a user mode process share a single address space. The kernel is located at the highest addresses.

On each architecture, the main user mode thread's stack starts near the highest user address and grows down.

FreeBSD architecture support varies by release. This table shows currently supported CPU architectures along with the first FreeBSD release to support each architecture.

  • aarch64 — initial release: 11.0
  • amd64 — initial release: 5.1
  • armv7 — initial release: 12.0
  • powerpc64 — initial release: 9.0
  • powerpc64le — initial release: 13.0
  • riscv64 — initial release: 12.0

Discontinued architectures are shown in the following table. rip to these icons, fr fr. 🕯️

  • alpha — initial release: 3.2; final release: 6.4
  • arm — initial release: 6.0; final release: 12.4
  • armeb — initial release: 8.0; final release: 11.4
  • armv6 — initial release: 10.0; final release: 14.x
  • ia64 — initial release: 5.0; final release: 10.4
  • i386 — initial release: 1.0; final release: 14.x
  • mips — initial release: 8.0; final release: 13.5
  • mipsel — initial release: 9.0; final release: 13.5
  • mipselhf — initial release: 12.0; final release: 13.5
  • mipshf — initial release: 12.0; final release: 13.5
  • mipsn32 — initial release: 9.0; final release: 13.5
  • mips64 — initial release: 9.0; final release: 13.5
  • mips64el — initial release: 9.0; final release: 13.5
  • mips64elhf — initial release: 12.0; final release: 13.5
  • mips64hf — initial release: 12.0; final release: 13.5
  • pc98 — initial release: 2.2; final release: 11.4
  • powerpc — initial release: 6.0; final release: 14.x
  • powerpcspe — initial release: 12.0; final release: 14.x
  • riscv64sf — initial release: 12.0; final release: 13.5
  • sparc64 — initial release: 5.0; final release: 12.4

🧮 Type sizes 🧮

All FreeBSD architectures use some variant of the ELF (see elf(5)) Application Binary Interface (ABI) for the machine processor. All supported ABIs can be divided into two groups:

  • ILP32 — int, long, void * types machine representations all have 4-byte size.
  • LP64 — int type machine representation uses 4 bytes, while long and void * are 8 bytes.

Some machines support more than one FreeBSD ABI. Typically these are 64-bit machines, where the “native” LP64 execution environment is accompanied by the “legacy” ILP32 environment, which was the historical 32-bit predecessor for 64-bit evolution. Examples are:

  • amd64 — ILP32 counterpart: i386
  • powerpc64 — ILP32 counterpart: powerpc
  • aarch64 — ILP32 counterpart: armv7

aarch64 will support execution of armv7 binaries if the CPU implements AArch32 execution state. Binaries targeting armv6 and earlier are no longer supported by FreeBSD. the old stuff is giving legacy, and not in the cute way. 💀

On all supported architectures:

  • short — size: 2
  • int — size: 4
  • long — size: sizeof(void*)
  • long long — size: 8
  • float — size: 4
  • double — size: 8

Integers are represented in two's complement. Alignment of integer and pointer types is natural, that is, the address of the variable must be congruent to zero modulo the type size. Most ILP32 ABIs, except arm, require only 4-byte alignment for 64-bit integers.

Machine-dependent type sizes:

  • aarch64 — void *: 8; long double: 16; time_t: 8
  • amd64 — void *: 8; long double: 16; time_t: 8
  • armv7 — void *: 4; long double: 8; time_t: 8
  • i386 — void *: 4; long double: 12; time_t: 4
  • powerpc — void *: 4; long double: 8; time_t: 8
  • powerpcspe — void *: 4; long double: 8; time_t: 8
  • powerpc64 — void *: 8; long double: 8; time_t: 8
  • powerpc64le — void *: 8; long double: 8; time_t: 8
  • riscv64 — void *: 8; long double: 16; time_t: 8

time_t is 8 bytes on all supported architectures except i386. not the i386 catching strays again 😭

🦋 Endianness and Char Signedness 🦋

  • aarch64 — endianness: little; char signedness: unsigned
  • amd64 — endianness: little; char signedness: signed
  • armv7 — endianness: little; char signedness: unsigned
  • i386 — endianness: little; char signedness: signed
  • powerpc — endianness: big; char signedness: unsigned
  • powerpcspe — endianness: big; char signedness: unsigned
  • powerpc64 — endianness: big; char signedness: unsigned
  • powerpc64le — endianness: little; char signedness: unsigned
  • riscv64 — endianness: little; char signedness: signed

📄 Page Size 📄

  • aarch64 — page sizes: 4K, 64K, 2M, 1G
  • amd64 — page sizes: 4K, 2M, 1G
  • armv7 — page sizes: 4K, 1M
  • i386 — page sizes: 4K, 2M (PAE), 4M
  • powerpc — page sizes: 4K
  • powerpcspe — page sizes: 4K
  • powerpc64 — page sizes: 4K
  • powerpc64le — page sizes: 4K
  • riscv64 — page sizes: 4K, 2M, 1G

🗺️ User Address Space Layout 🗺️

  • aarch64 — maximum address: 0x0001000000000000; address space size: 256TiB
  • amd64 (LA48) — maximum address: 0x0000800000000000; address space size: 128TiB
  • amd64 (LA57) — maximum address: 0x0100000000000000; address space size: 64PiB
  • armv7 — maximum address: 0xbfc00000; address space size: 3GiB
  • i386 — maximum address: 0xffc00000; address space size: 4GiB
  • powerpc — maximum address: 0xfffff000; address space size: 4GiB
  • powerpcspe — maximum address: 0x7ffff000; address space size: 2GiB
  • powerpc64 — maximum address: 0x000fffffc0000000; address space size: 4PiB
  • powerpc64le — maximum address: 0x000fffffc0000000; address space size: 4PiB
  • riscv64 (Sv39) — maximum address: 0x0000004000000000; address space size: 256GiB
  • riscv64 (Sv48) — maximum address: 0x0000800000000000; address space size: 128TiB

The layout of a process' address space can be queried via the KERN_PROC_VM_LAYOUT sysctl(3) MIB.

Historically, amd64 CPUs were limited to a 48-bit virtual address space. Newer CPUs support 5-level page tables, which extend the significant bits of addresses to 57 bits (LA57 mode). The address space layout is determined by the CPU's support for LA57. Setting the vm.pmap.la57 tunable to 0 forces the system into 4-level paging mode, even on hardware that supports 5-level paging. In this mode, all processes get a 48-bit address space. The vm.pmap.prefer_la48_uva tunable determines whether processes running on a LA57 system are limited to a 48-bit address space by default. Some applications make use of unused upper bits in pointer values to store information, and thus implicitly assume they are running in LA48 mode. To avoid breaking compatibility, all processes run in LA48 mode by default. The elfctl(1) utility can be used to request LA48 or LA57 mode for specific executables. Similarly, proccontrol(1) can be used to configure the address space layout when executing a process. LA57 is giving new-gen main character energy, but compatibility said “not today.” 💅

The RISC-V specification permits 3-level (Sv39), 4-level (Sv48), and 5-level (Sv57) page tables. Hardware is only required to implement Sv39; implementations which support Sv48 must also support Sv39, and implementations which support Sv57 must also support Sv48. The vm.pmap.mode tunable can be used to select the layout. FreeBSD currently supports Sv39 and Sv48 and defaults to using Sv39.

🌈 Floating Point 🌈

  • aarch64 — float, double: hard; long double: soft, quad precision
  • amd64 — float, double: hard; long double: hard, 80 bit
  • armv7 — float, double: hard; long double: hard, double precision
  • i386 — float, double: hard; long double: hard, 80 bit
  • powerpc — float, double: hard; long double: hard, double precision
  • powerpcspe — float, double: hard; long double: hard, double precision
  • powerpc64 — float, double: hard; long double: hard, double precision
  • powerpc64le — float, double: hard; long double: hard, double precision
  • riscv64 — float, double: hard; long double: hard, quad precision

🛠️ Default Tool Chain 🛠️

FreeBSD uses clang(1) as the default compiler on all supported CPU architectures, LLVM's ld.lld(1) as the default linker, and LLVM binary utilities such as objcopy(1) and readelf(1). the toolchain is lowkey iconic and consistent, periodt. 👑

👑 MACHINE_ARCH vs MACHINE_CPUARCH vs MACHINE 👑

MACHINE_CPUARCH should be preferred in Makefiles when the generic architecture is being tested. MACHINE_ARCH should be preferred when there is something specific to a particular type of architecture where there is a choice of many, or could be a choice of many. Use MACHINE when referring to the kernel, interfaces dependent on a specific type of kernel or similar things like boot sequences. okay so they are not interchangeable, bestie — read the room and use the right one. ✨

  • MACHINE = arm64 — MACHINE_CPUARCH: aarch64; MACHINE_ARCH: aarch64
  • MACHINE = amd64 — MACHINE_CPUARCH: amd64; MACHINE_ARCH: amd64
  • MACHINE = arm — MACHINE_CPUARCH: arm; MACHINE_ARCH: armv7
  • MACHINE = i386 — MACHINE_CPUARCH: i386; MACHINE_ARCH: i386
  • MACHINE = powerpc — MACHINE_CPUARCH: powerpc; MACHINE_ARCH: powerpc, powerpcspe, powerpc64, powerpc64le
  • MACHINE = riscv — MACHINE_CPUARCH: riscv; MACHINE_ARCH: riscv64

✨ Predefined Macros ✨

The compiler provides a number of predefined macros. Some of these provide architecture-specific details and are explained below. Other macros, including those required by the language standard, are not included here.

The full set of predefined macros can be obtained with this command:

cc -x c -dM -E /dev/null

Common type size and endianness macros:

  • __LP64__ — 64-bit (8-byte) long and pointer, 32-bit (4-byte) int
  • __ILP32__ — 32-bit (4-byte) int, long and pointer
  • BYTE_ORDER — Either BIG_ENDIAN or LITTLE_ENDIAN. PDP11_ENDIAN is not used on FreeBSD.

Architecture-specific macros:

  • aarch64 — __aarch64__
  • amd64 — __amd64__, __x86_64__
  • armv7 — __arm__, __ARM_ARCH >= 7
  • i386 — __i386__
  • powerpc — __powerpc__
  • powerpcspe — __powerpc__, __SPE__
  • powerpc64 — __powerpc__, __powerpc64__
  • powerpc64le — __powerpc__, __powerpc64__
  • riscv64 — __riscv, __riscv_xlen == 64

Compilers can also go off and define their own extra variants of architecture-specific macros — that's allowed. But for stuff in FreeBSD, the ones above are the preferred ones, periodt. 💅

🛠️ Important make(1) variables

Most of the variables you can set from the outside are documented over in the build(7) man page. The ones below are not documented anywhere else, and the build system uses them extensively — so like, pay attention bestie. 👀

  • MACHINE — this one's the hardware platform. It's literally the same thing as the native platform's uname(1) -m output. It defines both the userland/kernel interface and the bootloader/kernel interface, and it should only be used in those contexts. Here's the thing: each CPU architecture may support multiple hardware platforms where MACHINE differs between them. It's used to collect together all the files from config(8) to build the kernel. It's often the same as MACHINE_ARCH, because just like one CPU architecture can be implemented by many different hardware platforms, one hardware platform may support multiple CPU architecture family members — though with different binaries. Example time 🍓: the MACHINE of i386 supported the IBM-AT hardware platform, while the MACHINE of pc98 supported the Japanese company NEC's PC-9801 and PC-9821 hardware platforms. Both of those hardware platforms supported only the MACHINE_ARCH of i386, where they shared a common ABI — except for certain kernel/userland interfaces relating to underlying hardware platform differences in bus architecture, device enumeration and boot interface. Generally, MACHINE should only be used in src/sys and src/stand, or in system imagers or installers.
  • MACHINE_ARCH — the CPU processor architecture. Same as the native platform's uname(1) -p output. It defines the CPU instruction family that's supported, and it can also encode a lot of other stuff:
    • a variation in the byte ordering of multi-byte integers (endian) 🌈
    • a variation in the size of the integer or pointer
    • an ISA revision
    • hard versus soft floating point ABI and usage
    • a variant ABI, when the other factors don't uniquely define the ABI

It, along with MACHINE, defines the ABI used by the system. Generally the plain CPU name specifies the most common (or at least first) variant of the CPU — which is exactly why powerpc and powerpc64 imply 'big endian' while armv7 and aarch64 imply little endian. If we ever supported the so-called x32 ABI (using 32-bit pointers on the amd64 architecture), it would most likely be encoded as amd64-x32. And yeah, it's unfortunate that amd64 specifies the 64-bit evolution of the x86 platform (it matches the 'first rule') since almost everybody else uses x86_64. The FreeBSD port was so early that it predated processor name standardization after Intel joined the market — at the time, each OS just picked its own conventions. And backwards compatibility means it's not easy to change to the consensus name. 😭

  • MACHINE_CPUARCH — represents the source location for a given MACHINE_ARCH. It's generally the common prefix for all the MACHINE_ARCH values that share the same implementation, though riscv breaks this rule (iconic of it tbh). And while amd64 and i386 are closely related, MACHINE_CPUARCH is not x86 for them. The FreeBSD source base supports amd64 and i386 with two distinct source bases living in subdirectories named amd64 and i386 — though behind the scenes there's some sharing that fits into this framework. 🧚
  • CPUTYPE — sets the flavor of MACHINE_ARCH to build. It's used to optimize the build for a specific CPU/core that the binaries run on. Generally this does not change the ABI, though it can be a fine line between optimization for specific cases. ⚖️
  • TARGET — used to set MACHINE in the top level Makefile for cross building. It's unused outside of that scope, and it is not passed down to the rest of the build. Makefiles outside of the top level should not use it at all — though some have their own private copy for historical reasons, because of course they do. 💀
  • TARGET_ARCH — used to set MACHINE_ARCH by the top level Makefile for cross building. Like TARGET, it's unused outside of that scope.

🌈 SEE ALSO

elfctl(1), proccontrol(1), sysctl(3), src.conf(5), build(7), simd(7)

Go read them, bestie, they're all bangers. 📚✨

📜 HISTORY

An arch manual page appeared in FreeBSD 11.1. 👑

And that's the whole vibe check — this little Debian build of the page is dated July 14, 2025, and it's called ARCH(7). Slay, go forth and cross-compile responsibly. 🫶💖🎀
📦 where this page comes from