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, 0 insertions, 967 deletions
diff --git a/static/freebsd/man7/arch.7 3.html b/static/freebsd/man7/arch.7 3.html deleted file mode 100644 index 8172456e..00000000 --- a/static/freebsd/man7/arch.7 3.html +++ /dev/null @@ -1,967 +0,0 @@ -<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> |