ARM

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.

Processor vs architecture

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 architectures, 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.

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

The oldest architecture this compatibility 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).

Architecture extensions

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:

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.

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

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.

So for example, "armv4tl" is ARMv4 with Thumb extensions, little endian.

Application Binary Interface

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

So ARM has two ABIs that can run on the same hardware, the old one is called OABI and the new one is EABI. (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 aout to ELF executable formats.

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

Further Reading

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


Motorola 68000


Mips

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 registered trademark of MIPS Technologies, Inc.

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

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 number of licensees 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.

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.

The official version of this summary can be found at the company website.

Processors vs Cores

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.

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

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.

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.

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.

Compilers vs Features

Here is where the above headache begins to be felt.

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.

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.

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.


PowerPC


Super Hitachi


Sparc


x86