From 8da3a62701bd78adc6c2d9e3f858c593a82357c0 Mon Sep 17 00:00:00 2001
From: Chris Johns <chrisj@rtems.org>
Date: Wed, 6 Jul 2016 14:59:00 +1000
Subject: Add a Hardware section.

---
 user/hardware/architectures.rst | 55 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 user/hardware/architectures.rst

(limited to 'user/hardware/architectures.rst')

diff --git a/user/hardware/architectures.rst b/user/hardware/architectures.rst
new file mode 100644
index 0000000..1d6fd26
--- /dev/null
+++ b/user/hardware/architectures.rst
@@ -0,0 +1,55 @@
+.. comment SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. comment: Copyright (c) 2016 Chris Johns <chrisj@rtems.org>
+.. comment: All rights reserved.
+
+Architectures
+-------------
+.. index:: Architectures
+
+An RTEMS architecture is a class or family of a processor that RTEMS
+supports. The RTEMS architecture model follows the architecture model of
+GCC. An architecture in GCC results in a specific RTEMS GCC compiler. This
+compiler may support a range of processors in the family that may have
+differences in instructions sets or floating point support. RTEMS configures
+GCC to create separate runtime libraries for each supported instruction set and
+floating point unit in the architecture. This is termed **multlib**. Multlibs
+are manage automatically by GCC by selecting a specific instruction set or
+specific device in a family.
+
+RTEMS executables are statically linked for a specific target therefore a
+precise and exact match can be made for the hardware that extracts the best
+possible performance. The compiler supports the variants to the instruction set
+and RTEMS extends the specialization to specific processors in an
+architecture. This specialization gives RTEMS a finer resolution of features
+and capabilites a specific device may offer allowing the kernel, drivers and
+application to make the most of those resources. The trade off is portability
+however this is not important because the executable are statically linked for
+a single target.
+
+.. note::
+
+   RTEMS support dynamically load code through the ``dlopen``
+   interface. Loading code via this interface results in an executable image
+   that is equivalent to statically linked executable of the same code. Dynamic
+   loading is a system level tool for system architects.
+
+RTEMS supports 17 architectures:
+
+- arm
+- bfin
+- epiphany
+- i386
+- lm32
+- m32c
+- m68k
+- mips
+- moxie
+- nios2
+- no_cpu
+- or1k
+- powerpc
+- sh
+- sparc
+- sparc64
+- v850
-- 
cgit v1.2.3