diff options
Diffstat (limited to 'static/freebsd/man7/arch.7 3.html')
| -rw-r--r-- | static/freebsd/man7/arch.7 3.html | 967 |
1 files changed, 967 insertions, 0 deletions
diff --git a/static/freebsd/man7/arch.7 3.html b/static/freebsd/man7/arch.7 3.html new file mode 100644 index 00000000..8172456e --- /dev/null +++ b/static/freebsd/man7/arch.7 3.html @@ -0,0 +1,967 @@ +<table class="head"> + <tr> + <td class="head-ltitle">ARCH(7)</td> + <td class="head-vol">Miscellaneous Information Manual</td> + <td class="head-rtitle">ARCH(7)</td> + </tr> +</table> +<div class="manual-text"> +<section class="Sh"> +<h1 class="Sh" id="NAME"><a class="permalink" href="#NAME">NAME</a></h1> +<p class="Pp"><code class="Nm">arch</code> — + <span class="Nd">Architecture-specific details</span></p> +</section> +<section class="Sh"> +<h1 class="Sh" id="DESCRIPTION"><a class="permalink" href="#DESCRIPTION">DESCRIPTION</a></h1> +<p class="Pp">Differences between CPU architectures and platforms supported by + <span class="Ux">FreeBSD</span>.</p> +<section class="Ss"> +<h2 class="Ss" id="Introduction"><a class="permalink" href="#Introduction">Introduction</a></h2> +<p class="Pp">This document is a quick reference of key ABI details of + <span class="Ux">FreeBSD</span> architecture ports. For full details consult + the processor-specific ABI supplement documentation.</p> +<p class="Pp">If not explicitly mentioned, sizes are in bytes. The architecture + details in this document apply to <span class="Ux">FreeBSD 13.0</span> and + later, unless otherwise noted.</p> +<p class="Pp"><span class="Ux">FreeBSD</span> uses a flat address space. + Variables of types <var class="Vt">unsigned long</var>, + <var class="Vt">ptraddr_t</var>, and <var class="Vt">size_t</var> have the + same representation.</p> +<p class="Pp">In order to maximize compatibility with future pointer integrity + mechanisms, manipulations of pointers as integers should be performed via + <var class="Vt">uintptr_t</var> or <var class="Vt">intptr_t</var> 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, <var class="Vt">uintptr_t</var> and + <var class="Vt">intptr_t</var> are defined as + <var class="Vt">__uintcap_t</var> and <var class="Vt">__intcap_t</var> which + represent capabilities that can be manipulated by integer operations. + Pointers should not be cast to <var class="Vt">long</var>, + <var class="Vt">ptrdiff_t</var>, or <var class="Vt">size_t</var> 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.</p> +<p class="Pp">On some architectures, e.g., AIM variants of + <code class="Dv">powerpc64</code>, 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.</p> +<p class="Pp">On each architecture, the main user mode thread's stack starts + near the highest user address and grows down.</p> +<p class="Pp"><span class="Ux">FreeBSD</span> architecture support varies by + release. This table shows currently supported CPU architectures along with + the first <span class="Ux">FreeBSD</span> release to support each + architecture.</p> +<table class="Bl-column Bd-indent"> + <tr id="Architecture"> + <td><a class="permalink" href="#Architecture"><b class="Sy">Architecture</b></a></td> + <td><a class="permalink" href="#Initial"><b class="Sy" id="Initial">Initial + Release</b></a></td> + </tr> + <tr> + <td>aarch64</td> + <td>11.0</td> + </tr> + <tr> + <td>aarch64c</td> + <td>16.0 (planned)</td> + </tr> + <tr> + <td>amd64</td> + <td>5.1</td> + </tr> + <tr> + <td>armv7</td> + <td>12.0</td> + </tr> + <tr> + <td>powerpc64</td> + <td>9.0</td> + </tr> + <tr> + <td>powerpc64le</td> + <td>13.0</td> + </tr> + <tr> + <td>riscv64</td> + <td>12.0</td> + </tr> + <tr> + <td>riscv64c</td> + <td>16.0 (planned)</td> + </tr> +</table> +<p class="Pp">Discontinued architectures are shown in the following table.</p> +<table class="Bl-column Bd-indent"> + <tr id="Architecture~2"> + <td><a class="permalink" href="#Architecture~2"><b class="Sy">Architecture</b></a></td> + <td><a class="permalink" href="#Initial~2"><b class="Sy" id="Initial~2">Initial + Release</b></a></td> + <td><a class="permalink" href="#Final"><b class="Sy" id="Final">Final + Release</b></a></td> + </tr> + <tr> + <td>alpha</td> + <td>3.2</td> + <td>6.4</td> + </tr> + <tr> + <td>arm</td> + <td>6.0</td> + <td>12.4</td> + </tr> + <tr> + <td>armeb</td> + <td>8.0</td> + <td>11.4</td> + </tr> + <tr> + <td>armv6</td> + <td>10.0</td> + <td>14.x</td> + </tr> + <tr> + <td>ia64</td> + <td>5.0</td> + <td>10.4</td> + </tr> + <tr> + <td>i386</td> + <td>1.0</td> + <td>14.x</td> + </tr> + <tr> + <td>mips</td> + <td>8.0</td> + <td>13.5</td> + </tr> + <tr> + <td>mipsel</td> + <td>9.0</td> + <td>13.5</td> + </tr> + <tr> + <td>mipselhf</td> + <td>12.0</td> + <td>13.5</td> + </tr> + <tr> + <td>mipshf</td> + <td>12.0</td> + <td>13.5</td> + </tr> + <tr> + <td>mipsn32</td> + <td>9.0</td> + <td>13.5</td> + </tr> + <tr> + <td>mips64</td> + <td>9.0</td> + <td>13.5</td> + </tr> + <tr> + <td>mips64el</td> + <td>9.0</td> + <td>13.5</td> + </tr> + <tr> + <td>mips64elhf</td> + <td>12.0</td> + <td>13.5</td> + </tr> + <tr> + <td>mips64hf</td> + <td>12.0</td> + <td>13.5</td> + </tr> + <tr> + <td>pc98</td> + <td>2.2</td> + <td>11.4</td> + </tr> + <tr> + <td>powerpc</td> + <td>6.0</td> + <td>14.x</td> + </tr> + <tr> + <td>powerpcspe</td> + <td>12.0</td> + <td>14.x</td> + </tr> + <tr> + <td>riscv64sf</td> + <td>12.0</td> + <td>13.5</td> + </tr> + <tr> + <td>sparc64</td> + <td>5.0</td> + <td>12.4</td> + </tr> +</table> +</section> +<section class="Ss"> +<h2 class="Ss" id="Type_sizes"><a class="permalink" href="#Type_sizes">Type + sizes</a></h2> +<p class="Pp">All <span class="Ux">FreeBSD</span> architectures use some variant + of the ELF (see <a class="Xr">elf(5)</a>) + <a class="permalink" href="#Application"><b class="Sy" id="Application">Application + Binary Interface</b></a> (ABI) for the machine processor. Supported ABIs can + be divided into three main groups:</p> +<dl class="Bl-tag"> + <dt id="ILP32"><a class="permalink" href="#ILP32"><code class="Dv">ILP32</code></a></dt> + <dd><var class="Vt">int</var>, <var class="Vt">intptr_t</var>, + <var class="Vt">long</var>, and <var class="Vt">void *</var> types machine + representations all have 4-byte size.</dd> + <dt id="LP64"><a class="permalink" href="#LP64"><code class="Dv">LP64</code></a></dt> + <dd><var class="Vt">int</var> type machine representation uses 4 bytes, while + <var class="Vt">intptr_t</var>, <var class="Vt">long</var>, and + <var class="Vt">void *</var> are 8 bytes.</dd> + <dt id="L64PC128"><a class="permalink" href="#L64PC128"><code class="Dv">L64PC128</code></a></dt> + <dd><var class="Vt">int</var> type machine representation uses 4 bytes. + <var class="Vt">long</var> type machine representation uses 8 bytes. + <var class="Vt">intptr_t</var> and <var class="Vt">void *</var> are 16 + byte capabilities.</dd> +</dl> +<p class="Pp">Some machines support more than one + <span class="Ux">FreeBSD</span> ABI. Typically these are 64-bit machines, + where the “native” <code class="Dv">LP64</code> execution + environment is accompanied by the “legacy” + <code class="Dv">ILP32</code> environment, which was the historical 32-bit + predecessor for 64-bit evolution. Examples are:</p> +<table class="Bl-column Bd-indent"> + <tr id="LP64~2"> + <td><a class="permalink" href="#LP64~2"><b class="Sy">LP64</b></a></td> + <td><b class="Sy">ILP32 counterpart</b></td> + </tr> + <tr id="amd64"> + <td><a class="permalink" href="#amd64"><code class="Dv">amd64</code></a></td> + <td><a class="permalink" href="#i386"><code class="Dv" id="i386">i386</code></a></td> + </tr> + <tr id="powerpc64"> + <td><a class="permalink" href="#powerpc64"><code class="Dv">powerpc64</code></a></td> + <td><a class="permalink" href="#powerpc"><code class="Dv" id="powerpc">powerpc</code></a></td> + </tr> + <tr id="aarch64"> + <td><a class="permalink" href="#aarch64"><code class="Dv">aarch64</code></a></td> + <td><a class="permalink" href="#armv7"><code class="Dv" id="armv7">armv7</code></a></td> + </tr> +</table> +<p class="Pp"><code class="Dv">aarch64</code> will support execution of + <code class="Dv">armv7</code> binaries if the CPU implements + <code class="Dv">AArch32</code> execution state. Binaries targeting + <code class="Dv">armv6</code> and earlier are no longer supported by + <span class="Ux">FreeBSD</span>.</p> +<p class="Pp">Architectures with 128-bit capabilities support both a + “native” <code class="Dv">L64PC128</code> execution + environment and a <code class="Dv">LP64</code> environment:</p> +<table class="Bl-column Bd-indent"> + <tr id="L64PC128~2"> + <td><a class="permalink" href="#L64PC128~2"><b class="Sy">L64PC128</b></a></td> + <td><b class="Sy">LP64 counterpart</b></td> + </tr> + <tr id="aarch64c"> + <td><a class="permalink" href="#aarch64c"><code class="Dv">aarch64c</code></a></td> + <td><a class="permalink" href="#aarch64~2"><code class="Dv" id="aarch64~2">aarch64</code></a></td> + </tr> + <tr id="riscv64c"> + <td><a class="permalink" href="#riscv64c"><code class="Dv">riscv64c</code></a></td> + <td><a class="permalink" href="#riscv64"><code class="Dv" id="riscv64">riscv64</code></a></td> + </tr> +</table> +<p class="Pp">On all supported architectures:</p> +<table class="Bl-column Bd-indent"> + <tr id="Type"> + <td><a class="permalink" href="#Type"><b class="Sy">Type</b></a></td> + <td><a class="permalink" href="#Size"><b class="Sy" id="Size">Size</b></a></td> + </tr> + <tr> + <td>short</td> + <td>2</td> + </tr> + <tr> + <td>int</td> + <td>4</td> + </tr> + <tr> + <td>long long</td> + <td>8</td> + </tr> + <tr> + <td>float</td> + <td>4</td> + </tr> + <tr> + <td>double</td> + <td>8</td> + </tr> +</table> +<p class="Pp">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 + <code class="Dv">i386</code> requires only 4-byte alignment for 64-bit + integers.</p> +<p class="Pp">Machine-dependent type sizes:</p> +<table class="Bl-column Bd-indent"> + <tr id="Architecture~3"> + <td><a class="permalink" href="#Architecture~3"><b class="Sy">Architecture</b></a></td> + <td><a class="permalink" href="#long"><b class="Sy" id="long">long</b></a></td> + <td><a class="permalink" href="#void"><b class="Sy" id="void">void + *</b></a></td> + <td><b class="Sy">long double</b></td> + <td><a class="permalink" href="#time_t"><b class="Sy" id="time_t">time_t</b></a></td> + </tr> + <tr> + <td>aarch64</td> + <td>8</td> + <td>8</td> + <td>16</td> + <td>8</td> + </tr> + <tr> + <td>aarch64c</td> + <td>8</td> + <td>16</td> + <td>16</td> + <td>8</td> + </tr> + <tr> + <td>amd64</td> + <td>8</td> + <td>8</td> + <td>16</td> + <td>8</td> + </tr> + <tr> + <td>armv7</td> + <td>4</td> + <td>4</td> + <td>8</td> + <td>8</td> + </tr> + <tr> + <td>i386</td> + <td>4</td> + <td>4</td> + <td>12</td> + <td>4</td> + </tr> + <tr> + <td>powerpc</td> + <td>4</td> + <td>4</td> + <td>8</td> + <td>8</td> + </tr> + <tr> + <td>powerpcspe</td> + <td>4</td> + <td>4</td> + <td>8</td> + <td>8</td> + </tr> + <tr> + <td>powerpc64</td> + <td>8</td> + <td>8</td> + <td>8</td> + <td>8</td> + </tr> + <tr> + <td>powerpc64le</td> + <td>8</td> + <td>8</td> + <td>8</td> + <td>8</td> + </tr> + <tr> + <td>riscv64</td> + <td>8</td> + <td>8</td> + <td>16</td> + <td>8</td> + </tr> + <tr> + <td>riscv64c</td> + <td>8</td> + <td>16</td> + <td>16</td> + <td>8</td> + </tr> +</table> +<p class="Pp"><b class="Sy">time_t</b> is 8 bytes on all supported architectures + except i386.</p> +</section> +<section class="Ss"> +<h2 class="Ss" id="Endianness_and_Char_Signedness"><a class="permalink" href="#Endianness_and_Char_Signedness">Endianness + and Char Signedness</a></h2> +<table class="Bl-column Bd-indent"> + <tr id="Architecture~4"> + <td><a class="permalink" href="#Architecture~4"><b class="Sy">Architecture</b></a></td> + <td><a class="permalink" href="#Endianness"><b class="Sy" id="Endianness">Endianness</b></a></td> + <td><a class="permalink" href="#char"><b class="Sy" id="char">char + Signedness</b></a></td> + </tr> + <tr> + <td>aarch64</td> + <td>little</td> + <td>unsigned</td> + </tr> + <tr> + <td>aarch64c</td> + <td>little</td> + <td>unsigned</td> + </tr> + <tr> + <td>amd64</td> + <td>little</td> + <td>signed</td> + </tr> + <tr> + <td>armv7</td> + <td>little</td> + <td>unsigned</td> + </tr> + <tr> + <td>i386</td> + <td>little</td> + <td>signed</td> + </tr> + <tr> + <td>powerpc</td> + <td>big</td> + <td>unsigned</td> + </tr> + <tr> + <td>powerpcspe</td> + <td>big</td> + <td>unsigned</td> + </tr> + <tr> + <td>powerpc64</td> + <td>big</td> + <td>unsigned</td> + </tr> + <tr> + <td>powerpc64le</td> + <td>little</td> + <td>unsigned</td> + </tr> + <tr> + <td>riscv64</td> + <td>little</td> + <td>signed</td> + </tr> + <tr> + <td>riscv64c</td> + <td>little</td> + <td>signed</td> + </tr> +</table> +</section> +<section class="Ss"> +<h2 class="Ss" id="Page_Size"><a class="permalink" href="#Page_Size">Page + Size</a></h2> +<table class="Bl-column Bd-indent"> + <tr id="Architecture~5"> + <td><a class="permalink" href="#Architecture~5"><b class="Sy">Architecture</b></a></td> + <td><a class="permalink" href="#Page"><b class="Sy" id="Page">Page + Sizes</b></a></td> + </tr> + <tr> + <td>aarch64</td> + <td>4K, 64K, 2M, 1G</td> + </tr> + <tr> + <td>aarch64c</td> + <td>4K, 64K, 2M, 1G</td> + </tr> + <tr> + <td>amd64</td> + <td>4K, 2M, 1G</td> + </tr> + <tr> + <td>armv7</td> + <td>4K, 1M</td> + </tr> + <tr> + <td>i386</td> + <td>4K, 2M (PAE), 4M</td> + </tr> + <tr> + <td>powerpc</td> + <td>4K</td> + </tr> + <tr> + <td>powerpcspe</td> + <td>4K</td> + </tr> + <tr> + <td>powerpc64</td> + <td>4K</td> + </tr> + <tr> + <td>powerpc64le</td> + <td>4K</td> + </tr> + <tr> + <td>riscv64</td> + <td>4K, 2M, 1G</td> + </tr> + <tr> + <td>riscv64c</td> + <td>4K, 2M, 1G</td> + </tr> +</table> +</section> +<section class="Ss"> +<h2 class="Ss" id="User_Address_Space_Layout"><a class="permalink" href="#User_Address_Space_Layout">User + Address Space Layout</a></h2> +<table class="Bl-column Bd-indent"> + <tr id="Architecture~6"> + <td><a class="permalink" href="#Architecture~6"><b class="Sy">Architecture</b></a></td> + <td><a class="permalink" href="#Maximum"><b class="Sy" id="Maximum">Maximum + Address</b></a></td> + <td><a class="permalink" href="#Address"><b class="Sy" id="Address">Address + Space Size</b></a></td> + </tr> + <tr> + <td>aarch64</td> + <td>0x0001000000000000</td> + <td>256TiB</td> + </tr> + <tr> + <td>aarch64c</td> + <td>0x0001000000000000</td> + <td>256TiB</td> + </tr> + <tr> + <td>amd64 (LA48)</td> + <td>0x0000800000000000</td> + <td>128TiB</td> + </tr> + <tr> + <td>amd64 (LA57)</td> + <td>0x0100000000000000</td> + <td>64PiB</td> + </tr> + <tr> + <td>armv7</td> + <td>0xbfc00000</td> + <td>3GiB</td> + </tr> + <tr> + <td>i386</td> + <td>0xffc00000</td> + <td>4GiB</td> + </tr> + <tr> + <td>powerpc</td> + <td>0xfffff000</td> + <td>4GiB</td> + </tr> + <tr> + <td>powerpcspe</td> + <td>0x7ffff000</td> + <td>2GiB</td> + </tr> + <tr> + <td>powerpc64</td> + <td>0x000fffffc0000000</td> + <td>4PiB</td> + </tr> + <tr> + <td>powerpc64le</td> + <td>0x000fffffc0000000</td> + <td>4PiB</td> + </tr> + <tr> + <td>riscv64 (Sv39)</td> + <td>0x0000004000000000</td> + <td>256GiB</td> + </tr> + <tr> + <td>riscv64c (Sv39)</td> + <td>0x0000004000000000</td> + <td>256GiB</td> + </tr> + <tr> + <td>riscv64 (Sv48)</td> + <td>0x0000800000000000</td> + <td>128TiB</td> + </tr> + <tr> + <td>riscv64c (Sv48)</td> + <td>0x0000800000000000</td> + <td>128TiB</td> + </tr> +</table> +<p class="Pp">The layout of a process' address space can be queried via the + <code class="Dv">KERN_PROC_VM_LAYOUT</code> <a class="Xr">sysctl(3)</a> + MIB.</p> +<p class="Pp" id="vm.pmap.la57">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 + <a class="permalink" href="#vm.pmap.la57"><b class="Sy">vm.pmap.la57</b></a> + 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 + <a class="permalink" href="#vm.pmap.prefer_la48_uva"><b class="Sy" id="vm.pmap.prefer_la48_uva">vm.pmap.prefer_la48_uva</b></a> + 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 <a class="Xr">elfctl(1)</a> + utility can be used to request LA48 or LA57 mode for specific executables. + Similarly, <a class="Xr">proccontrol(1)</a> can be used to configure the + address space layout when executing a process.</p> +<p class="Pp" id="vm.pmap.mode">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 + <a class="permalink" href="#vm.pmap.mode"><b class="Sy">vm.pmap.mode</b></a> + tunable can be used to select the layout. <span class="Ux">FreeBSD</span> + currently supports Sv39 and Sv48 and defaults to using Sv39.</p> +</section> +<section class="Ss"> +<h2 class="Ss" id="Floating_Point"><a class="permalink" href="#Floating_Point">Floating + Point</a></h2> +<table class="Bl-column Bd-indent"> + <tr id="Architecture~7"> + <td><a class="permalink" href="#Architecture~7"><b class="Sy">Architecture</b></a></td> + <td><a class="permalink" href="#float,"><b class="Sy" id="float,">float, + double</b></a></td> + <td><b class="Sy">long double</b></td> + </tr> + <tr> + <td>aarch64</td> + <td>hard</td> + <td>soft, quad precision</td> + </tr> + <tr> + <td>aarch64c</td> + <td>hard</td> + <td>soft, quad precision</td> + </tr> + <tr> + <td>amd64</td> + <td>hard</td> + <td>hard, 80 bit</td> + </tr> + <tr> + <td>armv7</td> + <td>hard</td> + <td>hard, double precision</td> + </tr> + <tr> + <td>i386</td> + <td>hard</td> + <td>hard, 80 bit</td> + </tr> + <tr> + <td>powerpc</td> + <td>hard</td> + <td>hard, double precision</td> + </tr> + <tr> + <td>powerpcspe</td> + <td>hard</td> + <td>hard, double precision</td> + </tr> + <tr> + <td>powerpc64</td> + <td>hard</td> + <td>hard, double precision</td> + </tr> + <tr> + <td>powerpc64le</td> + <td>hard</td> + <td>hard, double precision</td> + </tr> + <tr> + <td>riscv64</td> + <td>hard</td> + <td>hard, quad precision</td> + </tr> + <tr> + <td>riscv64c</td> + <td>hard</td> + <td>hard, quad precision</td> + </tr> +</table> +</section> +<section class="Ss"> +<h2 class="Ss" id="Default_Tool_Chain"><a class="permalink" href="#Default_Tool_Chain">Default + Tool Chain</a></h2> +<p class="Pp"><span class="Ux">FreeBSD</span> uses <a class="Xr">clang(1)</a> as + the default compiler on all supported CPU architectures, LLVM's + <a class="Xr">ld.lld(1)</a> as the default linker, and LLVM binary utilities + such as <a class="Xr">objcopy(1)</a> and <a class="Xr">readelf(1)</a>.</p> +</section> +<section class="Ss"> +<h2 class="Ss" id="MACHINE_ARCH_vs_MACHINE_CPUARCH_vs_MACHINE"><a class="permalink" href="#MACHINE_ARCH_vs_MACHINE_CPUARCH_vs_MACHINE">MACHINE_ARCH + vs MACHINE_CPUARCH vs MACHINE</a></h2> +<p class="Pp"><code class="Dv">MACHINE_CPUARCH</code> should be preferred in + Makefiles when the generic architecture is being tested. + <code class="Dv">MACHINE_ARCH</code> 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 + <code class="Dv">MACHINE</code> when referring to the kernel, interfaces + dependent on a specific type of kernel or similar things like boot + sequences.</p> +<table class="Bl-column Bd-indent"> + <tr id="MACHINE"> + <td><a class="permalink" href="#MACHINE"><code class="Dv">MACHINE</code></a></td> + <td><a class="permalink" href="#MACHINE_CPUARCH"><code class="Dv" id="MACHINE_CPUARCH">MACHINE_CPUARCH</code></a></td> + <td><a class="permalink" href="#MACHINE_ARCH"><code class="Dv" id="MACHINE_ARCH">MACHINE_ARCH</code></a></td> + </tr> + <tr> + <td>arm64</td> + <td>aarch64</td> + <td>aarch64, aarch64c</td> + </tr> + <tr> + <td>amd64</td> + <td>amd64</td> + <td>amd64</td> + </tr> + <tr> + <td>arm</td> + <td>arm</td> + <td>armv7</td> + </tr> + <tr> + <td>i386</td> + <td>i386</td> + <td>i386</td> + </tr> + <tr> + <td>powerpc</td> + <td>powerpc</td> + <td>powerpc, powerpcspe, powerpc64, powerpc64le</td> + </tr> + <tr> + <td>riscv</td> + <td>riscv</td> + <td>riscv64, riscv64c</td> + </tr> +</table> +</section> +<section class="Ss"> +<h2 class="Ss" id="Predefined_Macros"><a class="permalink" href="#Predefined_Macros">Predefined + Macros</a></h2> +<p class="Pp">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.</p> +<p class="Pp">The full set of predefined macros can be obtained with this + command:</p> +<div class="Bd Pp Bd-indent Li"> +<pre>cc -x c -dM -E /dev/null</pre> +</div> +<p class="Pp">Common type size and endianness macros:</p> +<table class="Bl-column Bd-indent"> + <tr id="Macro"> + <td><a class="permalink" href="#Macro"><b class="Sy">Macro</b></a></td> + <td><a class="permalink" href="#Meaning"><b class="Sy" id="Meaning">Meaning</b></a></td> + </tr> + <tr id="__SIZEOF_LONG__"> + <td><a class="permalink" href="#__SIZEOF_LONG__"><code class="Dv">__SIZEOF_LONG__</code></a></td> + <td>size in bytes of long</td> + </tr> + <tr id="__SIZEOF_POINTER__"> + <td><a class="permalink" href="#__SIZEOF_POINTER__"><code class="Dv">__SIZEOF_POINTER__</code></a></td> + <td>size in bytes of intptr_t and pointers</td> + </tr> + <tr id="__SIZEOF_SIZE_T__"> + <td><a class="permalink" href="#__SIZEOF_SIZE_T__"><code class="Dv">__SIZEOF_SIZE_T__</code></a></td> + <td>size in bytes of size_t</td> + </tr> + <tr id="__LP64__"> + <td><a class="permalink" href="#__LP64__"><code class="Dv">__LP64__</code></a></td> + <td>64-bit (8-byte) long and pointer, 32-bit (4-byte) int</td> + </tr> + <tr id="__ILP32__"> + <td><a class="permalink" href="#__ILP32__"><code class="Dv">__ILP32__</code></a></td> + <td>32-bit (4-byte) int, long and pointer</td> + </tr> + <tr id="__CHERI__"> + <td><a class="permalink" href="#__CHERI__"><code class="Dv">__CHERI__</code></a></td> + <td>128-bit (16-byte) capability pointer, 64-bit (8-byte) long</td> + </tr> + <tr id="BYTE_ORDER"> + <td><a class="permalink" href="#BYTE_ORDER"><code class="Dv">BYTE_ORDER</code></a></td> + <td>Either <code class="Dv">BIG_ENDIAN or</code> + <code class="Dv">LITTLE_ENDIAN</code>.</td> + </tr> +</table> +<p class="Pp">Because systems were historically either + <code class="Dv">__ILP32__</code> or <code class="Dv">__LP64__</code> 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. <code class="Dv">__SIZEOF_*__</code> macros should be used instead. + New uses of <code class="Dv">__ILP32__</code> and + <code class="Dv">__LP64__</code> should be avoided. Compilers for CHERI + targets do not define <code class="Dv">__LP64__</code> as their pointers are + 128-bit capabilities.</p> +<p class="Pp">Architecture-specific macros:</p> +<table class="Bl-column Bd-indent"> + <tr id="Architecture~8"> + <td><a class="permalink" href="#Architecture~8"><b class="Sy">Architecture</b></a></td> + <td><a class="permalink" href="#Predefined"><b class="Sy" id="Predefined">Predefined + macros</b></a></td> + </tr> + <tr id="__aarch64__"> + <td>aarch64</td> + <td><a class="permalink" href="#__aarch64__"><code class="Dv">__aarch64__</code></a></td> + </tr> + <tr id="__aarch64__~2"> + <td>aarch64c</td> + <td><a class="permalink" href="#__aarch64__~2"><code class="Dv">__aarch64__</code></a>, + <code class="Dv">__CHERI__</code></td> + </tr> + <tr id="__amd64__"> + <td>amd64</td> + <td><a class="permalink" href="#__amd64__"><code class="Dv">__amd64__</code></a>, + <code class="Dv">__x86_64__</code></td> + </tr> + <tr id="__arm__"> + <td>armv7</td> + <td><a class="permalink" href="#__arm__"><code class="Dv">__arm__</code></a>, + <code class="Dv">__ARM_ARCH >= 7</code></td> + </tr> + <tr id="__i386__"> + <td>i386</td> + <td><a class="permalink" href="#__i386__"><code class="Dv">__i386__</code></a></td> + </tr> + <tr id="__powerpc__"> + <td>powerpc</td> + <td><a class="permalink" href="#__powerpc__"><code class="Dv">__powerpc__</code></a></td> + </tr> + <tr id="__powerpc__~2"> + <td>powerpcspe</td> + <td><a class="permalink" href="#__powerpc__~2"><code class="Dv">__powerpc__</code></a>, + <code class="Dv">__SPE__</code></td> + </tr> + <tr id="__powerpc__~3"> + <td>powerpc64</td> + <td><a class="permalink" href="#__powerpc__~3"><code class="Dv">__powerpc__</code></a>, + <code class="Dv">__powerpc64__</code></td> + </tr> + <tr id="__powerpc__~4"> + <td>powerpc64le</td> + <td><a class="permalink" href="#__powerpc__~4"><code class="Dv">__powerpc__</code></a>, + <code class="Dv">__powerpc64__</code></td> + </tr> + <tr id="__riscv"> + <td>riscv64</td> + <td><a class="permalink" href="#__riscv"><code class="Dv">__riscv</code></a>, + <code class="Dv">__riscv_xlen == 64</code></td> + </tr> + <tr id="__riscv~2"> + <td>riscv64c</td> + <td><a class="permalink" href="#__riscv~2"><code class="Dv">__riscv</code></a>, + <code class="Dv">__riscv_xlen == 64</code>, + <code class="Dv">__CHERI__</code></td> + </tr> +</table> +<p class="Pp">Compilers may define additional variants of architecture-specific + macros. The macros above are preferred for use in + <span class="Ux">FreeBSD</span>.</p> +</section> +<section class="Ss"> +<h2 class="Ss" id="Important_make_1_variables"><a class="permalink" href="#Important_make_1_variables">Important + <a class="Xr">make(1)</a> variables</a></h2> +<p class="Pp">Most of the externally settable variables are defined in the + <a class="Xr">build(7)</a> man page. These variables are not otherwise + documented and are used extensively in the build system.</p> +<dl class="Bl-tag"> + <dt id="MACHINE~2"><a class="permalink" href="#MACHINE~2"><code class="Dv">MACHINE</code></a></dt> + <dd>Represents the hardware platform. This is the same as the native + platform's <a class="Xr">uname(1)</a> <code class="Fl">-m</code> 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 + <code class="Dv">MACHINE</code> differs among them. It is used to collect + together all the files from <a class="Xr">config(8)</a> to build the + kernel. It is often the same as <code class="Dv">MACHINE_ARCH</code> 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, + <code class="Dv">MACHINE</code> of i386 supported the IBM-AT hardware + platform while the <code class="Dv">MACHINE</code> of pc98 supported the + Japanese company NEC's PC-9801 and PC-9821 hardware platforms. Both of + these hardware platforms supported only the + <code class="Dv">MACHINE_ARCH</code> 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, <code class="Dv">MACHINE</code> + should only be used in src/sys and src/stand or in system imagers or + installers.</dd> + <dt id="MACHINE_ARCH~2"><a class="permalink" href="#MACHINE_ARCH~2"><code class="Dv">MACHINE_ARCH</code></a></dt> + <dd>Represents the CPU processor architecture. This is the same as the native + platforms <a class="Xr">uname(1)</a> <code class="Fl">-p</code> 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 + <code class="Dv">MACHINE</code>, 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 + <span class="Ux">FreeBSD</span> 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.</dd> + <dt id="MACHINE_CPUARCH~2"><a class="permalink" href="#MACHINE_CPUARCH~2"><code class="Dv">MACHINE_CPUARCH</code></a></dt> + <dd>Represents the source location for a given + <code class="Dv">MACHINE_ARCH</code>. 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 <span class="Ux">FreeBSD</span> + 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).</dd> + <dt id="CPUTYPE"><a class="permalink" href="#CPUTYPE"><code class="Dv">CPUTYPE</code></a></dt> + <dd>Sets the flavor of <code class="Dv">MACHINE_ARCH</code> 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.</dd> + <dt id="TARGET"><a class="permalink" href="#TARGET"><code class="Dv">TARGET</code></a></dt> + <dd>Used to set <code class="Dv">MACHINE</code> 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).</dd> + <dt id="TARGET_ARCH"><a class="permalink" href="#TARGET_ARCH"><code class="Dv">TARGET_ARCH</code></a></dt> + <dd>Used to set <code class="Dv">MACHINE_ARCH</code> by the top level Makefile + for cross building. Like <code class="Dv">TARGET</code>, it is unused + outside of that scope.</dd> +</dl> +</section> +</section> +<section class="Sh"> +<h1 class="Sh" id="SEE_ALSO"><a class="permalink" href="#SEE_ALSO">SEE + ALSO</a></h1> +<p class="Pp"><a class="Xr">elfctl(1)</a>, <a class="Xr">proccontrol(1)</a>, + <a class="Xr">sysctl(3)</a>, <a class="Xr">src.conf(5)</a>, + <a class="Xr">build(7)</a>, <a class="Xr">simd(7)</a></p> +</section> +<section class="Sh"> +<h1 class="Sh" id="HISTORY"><a class="permalink" href="#HISTORY">HISTORY</a></h1> +<p class="Pp">An <code class="Nm">arch</code> manual page appeared in + <span class="Ux">FreeBSD 11.1</span>.</p> +</section> +</div> +<table class="foot"> + <tr> + <td class="foot-date">November 27, 2025</td> + <td class="foot-os">FreeBSD 15.0</td> + </tr> +</table> |