---
name: "arch"
section: "7"
platform: "freebsd"
package: "base"
version: "16.0-CURRENT-20261027-61c70dc16a79"
release: "FreeBSD 16.0-CURRENT (2026-10-27)"
platforms: ["freebsd"]
url: "https://new.carta.tech/arch/7"
---

# arch(7)

Architecture-specific details

## NAME

**arch** – Architecture-specific details

## DESCRIPTION

Differences between CPU architectures and platforms supported by FreeBSD.

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

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*, *ptraddr\_t*, and *size\_t* 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 as these types are the only integer types where the C standard guarantees that a pointer may be cast to it and then cast back to the original type. On CHERI systems, *uintptr\_t* and *intptr\_t* are defined as *\_\_uintcap\_t* and *\_\_intcap\_t* which represent capabilities that can be manipulated by integer operations. Pointers should not be cast to *long*, *ptrdiff\_t*, or *size\_t* if they will later be cast back to a pointer that is expected to be dereferenceable as they remain bare integer types on all architectures.

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.

| | |
| --- | --- |
| **Architecture** | **Initial** **Release** |
| aarch64 | 11.0 |
| aarch64c | 16.0 (planned) |
| amd64 | 5.1 |
| armv7 | 12.0 |
| powerpc64 | 9.0 |
| powerpc64le | 13.0 |
| riscv64 | 12.0 |
| riscv64c | 16.0 (planned) |

Discontinued architectures are shown in the following table.

| | | |
| --- | --- | --- |
| **Architecture** | **Initial** **Release** | **Final** **Release** |
| alpha | 3.2 | 6.4 |
| arm | 6.0 | 12.4 |
| armeb | 8.0 | 11.4 |
| armv6 | 10.0 | 14.x |
| ia64 | 5.0 | 10.4 |
| i386 | 1.0 | 14.x |
| mips | 8.0 | 13.5 |
| mipsel | 9.0 | 13.5 |
| mipselhf | 12.0 | 13.5 |
| mipshf | 12.0 | 13.5 |
| mipsn32 | 9.0 | 13.5 |
| mips64 | 9.0 | 13.5 |
| mips64el | 9.0 | 13.5 |
| mips64elhf | 12.0 | 13.5 |
| mips64hf | 12.0 | 13.5 |
| pc98 | 2.2 | 11.4 |
| powerpc | 6.0 | 14.x |
| powerpcspe | 12.0 | 14.x |
| riscv64sf | 12.0 | 13.5 |
| sparc64 | 5.0 | 12.4 |

### Type Sizes

All FreeBSD architectures use some variant of the ELF (see [elf(5)](/elf/5.md)) **Application** **Binary** **Interface** (ABI) for the machine processor. Supported ABIs can be divided into three main groups:

- ILP32

  *int*, *intptr\_t*, *long*, and *void* *\** types machine representations all have 4-byte size.

- LP64

  *int* type machine representation uses 4 bytes, while *intptr\_t*, *long*, and *void* *\** are 8 bytes.

- L64PC128

  *int* type machine representation uses 4 bytes. *long* type machine representation uses 8 bytes. *intptr\_t* and *void* *\** are 16 byte capabilities.

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:

| | |
| --- | --- |
| **LP64** | **ILP32** **counterpart** |
| amd64 | i386 |
| powerpc64 | powerpc |
| aarch64 | 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.

Architectures with 128-bit capabilities support both a “native” L64PC128 execution environment and a LP64 environment:

| | |
| --- | --- |
| **L64PC128** | **LP64** **counterpart** |
| aarch64c | aarch64 |
| riscv64c | riscv64 |

On all supported architectures:

| | |
| --- | --- |
| **Type** | **Size** |
| short | 2 |
| int | 4 |
| long long | 8 |
| float | 4 |
| double | 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. The sole exception is that i386 requires only 4-byte alignment for 64-bit integers.

Machine-dependent type sizes:

| | | | | |
| --- | --- | --- | --- | --- |
| **Architecture** | **long** | **void** **\*** | **long** **double** | **time\_t** |
| aarch64 | 8 | 8 | 16 | 8 |
| aarch64c | 8 | 16 | 16 | 8 |
| amd64 | 8 | 8 | 16 | 8 |
| armv7 | 4 | 4 | 8 | 8 |
| i386 | 4 | 4 | 12 | 4 |
| powerpc | 4 | 4 | 8 | 8 |
| powerpc64 | 8 | 8 | 8 | 8 |
| powerpc64le | 8 | 8 | 16 | 8 |
| riscv64 | 8 | 8 | 16 | 8 |
| riscv64c | 8 | 16 | 16 | 8 |

**time\_t** is 8 bytes on all supported architectures except i386.

### Endianness and char Signedness

| | | | |
| --- | --- | --- | --- |
| **Architecture** | **Endianness** | **char** **Signedness** | **wchar\_t** **Signedness** |
| aarch64 | little | unsigned | unsigned |
| aarch64c | little | unsigned | unsigned |
| amd64 | little | signed | signed |
| armv7 | little | unsigned | unsigned |
| i386 | little | signed | signed |
| powerpc | big | unsigned | signed |
| powerpc64 | big | unsigned | signed |
| powerpc64le | little | unsigned | signed |
| riscv64 | little | signed | signed |
| riscv64c | little | signed | signed |

### Page Size

| | |
| --- | --- |
| **Architecture** | **Page** **Sizes** |
| aarch64 | 4K, 64K, 2M, 1G |
| aarch64c | 4K, 64K, 2M, 1G |
| amd64 | 4K, 2M, 1G |
| armv7 | 4K, 1M |
| i386 | 4K, 2M (PAE), 4M |
| powerpc | 4K |
| powerpc64 | 4K |
| powerpc64le | 4K |
| riscv64 | 4K, 2M, 1G |
| riscv64c | 4K, 2M, 1G |

### User Address Space Layout

| | | |
| --- | --- | --- |
| **Architecture** | **Maximum** **Address** | **Address** **Space** **Size** |
| aarch64 | 0x0001000000000000 | 256TiB |
| aarch64c | 0x0001000000000000 | 256TiB |
| amd64 (LA48) | 0x0000800000000000 | 128TiB |
| amd64 (LA57) | 0x0100000000000000 | 64PiB |
| armv7 | 0xbfc00000 | 3GiB |
| i386 | 0xffc00000 | 4GiB |
| powerpc | 0xfffff000 | 4GiB |
| powerpc64 | 0x000fffffc0000000 | 4PiB |
| powerpc64le | 0x000fffffc0000000 | 4PiB |
| riscv64 (Sv39) | 0x0000004000000000 | 256GiB |
| riscv64c (Sv39) | 0x0000004000000000 | 256GiB |
| riscv64 (Sv48) | 0x0000800000000000 | 128TiB |
| riscv64c (Sv48) | 0x0000800000000000 | 128TiB |

The layout of a process' address space can be queried via the KERN\_PROC\_VM\_LAYOUT [sysctl(3)](/sysctl/3.md) 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)](/elfctl/1.md) utility can be used to request LA48 or LA57 mode for specific executables. Similarly, [proccontrol(1)](/proccontrol/1.md) can be used to configure the address space layout when executing a process.

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

| | | |
| --- | --- | --- |
| **Architecture** | **float,** **double** | **long** **double** |
| aarch64 | hard | soft, quad precision |
| aarch64c | hard | soft, quad precision |
| amd64 | hard | hard, 80 bit |
| armv7 | hard | hard, double precision |
| i386 | hard | hard, 80 bit |
| powerpc | hard | hard, double precision |
| powerpc64 | hard | hard, double precision |
| powerpc64le | hard | soft, quad precision |
| riscv64 | hard | hard, quad precision |
| riscv64c | hard | hard, quad precision |

### Default Tool Chain

FreeBSD uses [clang(1)](/clang/1.md) as the default compiler on all supported CPU architectures, LLVM's [ld.lld(1)](/ld.lld/1.md) as the default linker, and LLVM binary utilities such as [objcopy(1)](/objcopy/1.md) and [readelf(1)](/readelf/1.md).

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

| | | |
| --- | --- | --- |
| MACHINE | MACHINE\_CPUARCH | MACHINE\_ARCH |
| arm64 | aarch64 | aarch64, aarch64c |
| amd64 | amd64 | amd64 |
| arm | arm | armv7 |
| i386 | i386 | i386 |
| powerpc | powerpc | powerpc, powerpc64, powerpc64le |
| riscv | riscv | riscv64, riscv64c |

### 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:

| | |
| --- | --- |
| **Macro** | **Meaning** |
| \_\_SIZEOF\_LONG\_\_ | size in bytes of long |
| \_\_SIZEOF\_POINTER\_\_ | size in bytes of intptr\_t and pointers |
| \_\_SIZEOF\_SIZE\_T\_\_ | size in bytes of size\_t |
| \_\_LP64\_\_ | 64-bit (8-byte) long and pointer, 32-bit (4-byte) int |
| \_\_ILP32\_\_ | 32-bit (4-byte) int, long and pointer |
| \_\_CHERI\_\_ | 128-bit (16-byte) capability pointer, 64-bit (8-byte) long |
| BYTE\_ORDER | Either BIG\_ENDIAN or LITTLE\_ENDIAN. |

Because systems were historically either \_\_ILP32\_\_ or \_\_LP64\_\_ it has been common for programmers to test only one and assume the other one in an else branch. With the arrival of CHERI architectures, this is no longer the case. \_\_SIZEOF\_\*\_\_ macros should be used instead. New uses of \_\_ILP32\_\_ and \_\_LP64\_\_ should be avoided. Compilers for CHERI targets do not define \_\_LP64\_\_ as their pointers are 128-bit capabilities.

Architecture-specific macros:

| | |
| --- | --- |
| **Architecture** | **Predefined** **macros** |
| aarch64 | \_\_aarch64\_\_ |
| aarch64c | \_\_aarch64\_\_, \_\_CHERI\_\_ |
| amd64 | \_\_amd64\_\_, \_\_x86\_64\_\_ |
| armv7 | \_\_arm\_\_, \_\_ARM\_ARCH \>= 7 |
| i386 | \_\_i386\_\_ |
| powerpc | \_\_powerpc\_\_ |
| powerpc64 | \_\_powerpc\_\_, \_\_powerpc64\_\_ |
| powerpc64le | \_\_powerpc\_\_, \_\_powerpc64\_\_ |
| riscv64 | \_\_riscv, \_\_riscv\_xlen == 64 |
| riscv64c | \_\_riscv, \_\_riscv\_xlen == 64, \_\_CHERI\_\_ |

Compilers may define additional variants of architecture-specific macros. The macros above are preferred for use in FreeBSD.

### Important Xr make 1 variables

Most of the externally settable variables are defined in the [build(7)](/build/7.md) man page. These variables are not otherwise documented and are used extensively in the build system.

- MACHINE

  Represents the hardware platform. This is the same as the native platform's [uname(1)](/uname/1.md) **-m** output. It defines both the userland / kernel interface, as well as the bootloader / kernel interface. It should only be used in these contexts. Each CPU architecture may have multiple hardware platforms it supports where MACHINE differs among them. It is used to collect together all the files from [config(8)](/config/8.md) to build the kernel. It is often the same as MACHINE\_ARCH just as 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. For example, 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 these 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

  Represents the CPU processor architecture. This is the same as the native platforms [uname(1)](/uname/1.md) **-p** output. It defines the CPU instruction family supported. It may also encode a variation in the byte ordering of multi-byte integers (endian). It may also encode a variation in the size of the integer or pointer. It may also encode a ISA revision. It may also encode hard versus soft floating point ABI and usage. It may also encode a variant ABI when the other factors do not 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. This is why powerpc and powerpc64 imply 'big endian' while armv7 and aarch64 imply little endian. If we ever were to support the so-called x32 ABI (using 32-bit pointers on the amd64 architecture), it would most likely be encoded as amd64-x32. It is unfortunate that amd64 specifies the 64-bit evolution of the x86 platform (it matches the 'first rule') as almost everybody else uses x86\_64. The FreeBSD port was so early, it predated processor name standardization after Intel joined the market. At the time, each OS selected its own conventions. Backwards compatibility means it is not easy to change to the consensus name.

- MACHINE\_CPUARCH

  Represents the source location for a given MACHINE\_ARCH. It is generally the common prefix for all the MACHINE\_ARCH that share the same implementation, though 'riscv' breaks this rule. 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 is 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. Unused outside of that scope. 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).

- TARGET\_ARCH

  Used to set MACHINE\_ARCH by the top level Makefile for cross building. Like TARGET, it is unused outside of that scope.

## SEE ALSO

[elfctl(1)](/elfctl/1.md), [proccontrol(1)](/proccontrol/1.md), [sysctl(3)](/sysctl/3.md), [src.conf(5)](/src.conf/5.md), [build(7)](/build/7.md), [simd(7)](/simd/7.md)

## HISTORY

An **arch** manual page appeared in FreeBSD 11.1.