view www/architectures.html @ 1229:313c702a0984

Remove toybox.
author Rob Landley <>
date Tue, 24 Aug 2010 03:08:47 -0500
parents f5b13cbc77d7
children d4eb237dcc6f
line wrap: on
line source

<title>Target architectures</title>

<!--#include file="header.html" -->

<hr /><h1><a name="arm" \><center>ARM</center></h1>

<p>The ARM processor is popular in the embedded space because it has the best
power consumption to performance ratio, meaning it has the longest battery
life and smallest amount of heat generated for a given computing task.</p>

<h2>Processor vs archtecture</h2>

<p>Although ARM hardware has many different processor designs with varying
clock speeds, cache sizes, and integrated peripherals, from a software
perspective what matters is ARM
<a href=>architectures</a>, which are the different
instruction sets a compiler can produce.  The architecture names have a "v"
in them and the processor designs don't, so "ARM922T" is a hardware processor
design which implements the "ARMv4T" software instruction set.</p>

<p>The basic architectures are numbered: ARMv3, ARMv4, ARMv5, ARMv6, and
ARMv7.  An ARMv5 capable processor can run ARMv4 binaries, ARMv6 can run ARMv5,
and so on.  Each new architecture is a superset of the old ones, and the main
reason to compile for newer platforms is efficiency: faster speed and better
battery life.  (I.E. they work about like i386, i486, i586, and i686 do in
the x86 world.  Recompiling ARMv4 code to ARMv5 code provides about a 25%
speedup on the same hardware.)</p>

<p>The oldest architecture this compatability goes back to is ARMv3 (which
introduced 32-bit addressing), but that hardware is now obsolete.  (Not just no
longer being sold, but mostly cycled out of the installed base.)  The oldest
architecture still in use is "ARMv4", which should run on any ARM hardware
still in use today (except ARMv7M, which is ARM in name only).</p>

<h2>Architecture extensions</h2>

<p>ARM architectures can have several instruction set extensions, indicated
by letters after the ARMv# part.  Some (such as the letter "E" denoting the
"Jazelle" bytecode interpreter, which provides hardware acceleration for
running Java bytecode) can safely be ignored if you're not using them, and
others are essentially always there in certain architectures (such as the DSP
extension signified by the letter "E" which always seems to be present in
ARMv5).  But some are worth mentioning:</p>

<p>The "Thumb" extension (ARMv4T) adds
a smaller instruction set capable of fitting more code in a given amount
of memory.  Unfortunately thumb instructions sometimes run more slowly, and
the instruction set isn't complete enough to implement a kernel, so they
supplement rather than replace the conventional ARM instruction set.  Note
that all ARMv5 and later processors include Thumb support by default, only
ARMv4T offers it as an extension.  Also, a new "Thumb2" fixes most of the
deficiencies of the original Thumb, and is part of the ARMv7 architecture.</p>

<p>The VFP (Vector Floating Point) coprocessor provides hardware floating
point acceleration.  There are some older hardware floating point options,
and some newer ones backwards compatible with VFP, but in general you can
treat a chip as either "software floating point" or "VFP".</p>

<p>The other detail is "l" vs "b" for little-endian and big-endian.
In theory ARM can do both (this is a compiler distinction, not a hardware
distinction), but in practice little-endian is almost universally
used on ARM, and most boards are wired up to support little-endian only even if
the processor itself can theoretically handle both.</p>

<p>So for example, "armv4tl" is ARMv4 with Thumb extensions, little endian.</p>

<h2>Application Binary Interface</h2>

<p>Linux initially implemented a somewhat ad-hoc ABI for ARM with
<a href=>poor
performance and several limitations</a>, and when ARM got around to documenting
a new one the main downside was that it was incompatible with the old

<p>So ARM has two ABIs that can run on the same hardware, the old one is
called OABI and the new one is
<a href=>EABI</a>.  (This is a bit like
the way BSD binaries won't run under Linux even though the hardware's the
same, or the long ago switch from
<a href=>aout to ELF</a> executable

<p>The oldest hardware that can run EABI is ARMv4T, so ARMv4 hardware
without the Thumb extensions still has to use OABI.  (The kernel, C
library, and compiler must all agree which ABI is in use or the binaries
won't run.)</p>

<h2>Further Reading</h2>

<p>In theory the best reference for ARM processors is the
<a href=>website of ARM Limited</a>, but unfortunately
they make it somewhat hard to find information about their
<a href=>older products</a>
and <a href=>many
of their pages</a> are more concerned with advertising their newest products
than giving the requested information.  Wikipedia may be less frustrating,
and occasionally even accurate.</p>

<hr /><h1><a name="m68k" \><center>Motorola 68000</center></h2>
<hr /><h1><a name="mips" \><center>Mips</center></h1>
<P ALIGN=LEFT>Originally the acronym MIPS stood for: Microprocessor
without Interlocked Pipeline Stages. The phrase describes a RISC
architecture design goal of the Stanford University team led by John
L. Hennessy in 1981.  It is also a <A HREF="">registered
trademark</A> of MIPS Technologies, Inc.</P>
<P ALIGN=LEFT>During the first two decades, the company's main
business was the production of complete processors.  During the most
recent decade, the company's main business has been the licensing of
their processor architecture for inclusion into products of other
<P ALIGN=LEFT>The MIPS processor core designs of MIPS Technologies,
Inc. have a significant portion of the custom silicon market place. 
This is a result of the <A HREF="">number
of licensees</A> that use the MIPS processor core design as a
component of their own products.  Their component cores are used in
silicon designs of all sizes, from Smart Cards to complex SoC (System
on Chip) parts.  
<P ALIGN=LEFT>The major point that the company emphasizes about their
designs is through-put performance versus silicon area.  One of Dr.
Hennessy's original objectives.  Dr. Hennessy is now the 10th
president of Stanford University.</P>
<P ALIGN=LEFT>The official version of this summary can be found at
<A HREF="" NAME="">the company website.</A></P>
<H2>Processors vs Cores</H2>
<P>During the first two decades, the company built complete
processors.  They also licensed their processor designs to other
manufacturers.  Here, “processors” can be thought of as some
device that you plug or solder onto a circuit board.  These complete
devices where predominately revision 1 MIPS architecture.</P>
<P>During the most recent decade the company licensed others to
include their Intellectual Property (processor core designs) into the
 products of those other companies.  Here, “cores” can be thought
of as include files that a silicon designer plugs into their design
<P>These core designs are available to the MIPS licensees as sets of
features.  The licensee of MIPS can mix and match the feature sets to
suit their own design goals.  These core designs are predominately
the revision 2 MIPS architecture. 
<P>This can be a great advantage to the licensee; they only spend
silicon area on the features their design needs.  At the same time
this can be a great headache to anyone who is trying to match
compiler code generation to whatever collection of features are
present on a specific device.</P>
<P>Also a great headache even to the authors of software build
systems.  With a MIPS Technology device, the authors of the build
system can not simply say: “Look at the model number and insert
that model number into configuration file xyz”.  Some other means
of guiding the build system user is required and often build systems
don't even try.</P>
<H2>Compilers vs Features</H2>
<P>Here is where the above headache begins to be felt.</P>
<P>On the bright side, MIPS Technologies provides their licensees
reference software materials.  This includes a MIPS designed system
boot loader that can report all the key facts about the core it is
running on at power-up time.  Not all licensees use this system boot
loader but many do use it.</P>
<P>The boot loader report or the output report of a similar hardware
feature detection program is your best guide to knowing what compiler
options you should be using for your build system.  It will at least
identify the base architecture by name or number.</P>
<P>In general, you want to select the overall architecture option
that matches the base architecture design.  That should (if the
compiler your using is at all sane) get you code that will run at
least well enough to discover all of the hardware details.</P>
<hr /><h1><a name="ppc" \><center>PowerPC</center></h1>
<hr /><h1><a name="sh4" \><center>Super Hitachi</center></h1>
<hr /><h1><a name="sparc" \><center>Sparc</center></h1>
<hr /><h1><a name="x86" \><center>x86</center></h1>

<!--#include file="footer.html" -->