Differences between ColdFire & 68K (original) (raw)

Differences between 680x0 family and ColdFire

Although the ColdFire architecture is closely related to the 680x0, there are many simplifications to the instruction set. Nearly all of the differences are omissions from the 680x0 instruction set and addressing modes. This means that (with a few important exceptions detailed below), a 680x0 instruction which is implemented in ColdFire behaves in exactly the same way under the two architectures. In fact, almost all user-level (and much supervisor-level) ColdFire code can be run unchanged on a 68020 or later 680x0 processor (apart from new instructions introduced in the Version 4 ColdFire core). The converse, however, is not the case.

In outline, the main omissions fall into five categories:

Principles behind the differences

In order to understand the ColdFire instruction set in relation to that of the 680x0, it helps to have an appreciation of why the simplifications have been made. The philosophy behind ColdFire is influenced by the success of RISC processors in providing high performance - for a given degree of chip complexity - by eliminating seldom-used instructions and complex addressing modes, and by regularizing the instruction set to make it easier for the hardware to optimize despatch of the instruction stream.

However, standard RISC processors such as the PowerPC achieve high performance at the expense of low code density, in part because all instructions are the same width (generally 4 bytes) and also because only very simple addressing modes are available. In addition, RISC processors do not allow direct modification of memory locations; all memory reads and writes have to go via registers. This all means that programs compiled for RISC processors tend to be substantially larger than those compiled for CISC architectures such as the 680x0. This penalty does not greatly matter for desktop systems or servers with gigabytes of RAM, but for embedded applications it can be a significant disadvantage, both in terms of system cost and power consumption.

The ColdFire architecture - which Freescale Semiconductor characterized as "Variable-Length RISC" - aims to share many of the speed advantages of RISC, without losing too much of the code density advantages of the 680x0 family. Like most modern processor architectures, it is optimized for code written in C or C++, and instructions which are not frequently generated by compilers are amongst those removed from the instruction set. Some of the complex addressing modes - again not important for compilers - are eliminated, and the additional hardware complexities involved in supporting arithmetic operations on bytes and words also disappear. In order to regularize the instruction stream, all ColdFire instructions are either 2, 4 or 6 bytes wide; this is why certain combinations of source and destination operands are not available.

Missing addressing modes

The ColdFire addressing modes are quite similar to those of the original 68000, i.e. without the extensions introduced in the 68020 and later processors, but with some differences in indexed addressing. Compared with a 68020 or later processor, the comparison is as follows:

Fully supported:
Partially supported:

The restrictions on these two modes are:

Not implemented at all:

Note that further restrictions may be imposed on the addressing modes supported by particular instructions, even if a particular addressing mode is itself available on ColdFire.

Missing instructions

A number of instructions are not implemented at all under ColdFire. These include:

DBcc, EXG, RTR, RTD, CMPM,

ROL, ROR, ROXL, ROXR, MOVE16

ABCD, SBCD, NBCD

BFCHG, BFCLR, BFEXTS, BFEXTU

BFFFO, BFINS, BFSET, BFTST

CALLM, RTM, PACK, UNPK

CHK, CHK2, CMP2, CAS, CAS2, TAS (restored in V4 core),

BKPT, BGND, LPSTOP, TBLU, TBLS, TBLUN, TBLSN

TRAPV, TRAPcc, MOVEP, MOVES, RESET

ORI to CCR, EORI to CCR, ANDI to CCR

In addition, DIVS and DIVU (with some differences from the 680x0 equivalents) are available on some ColdFire processors but not others. MULU and MULS producing a 64-bit result are not implemented, but 16 x 16 producing 32-bit, and 32 x 32 producing (truncated) 32-bit, are available.

Long-word forms only

Most arithmetic and logical instructions can act on Long words only. This applies to:

ADD, ADDA, ADDI, ADDQ, ADDX, AND, ANDI, ASL, ASR

CMP, CMPI (word/byte forms re-introduced in version 4 core)

CMPA, EOR, EORI, LSL, LSR,

NEG, NEGX, NOT, OR, ORI,

SUB, SUBA, SUBI, SUBQ, SUBX

MOVEM.W has also been removed from the instruction set.

In fact, the only instructions which do act on the full set of byte, word and long operands are CLR, MOVE and TST (and CMP and CMPI in the version 4 core). EXT.W, EXTB.L and EXT.L survive, as do MULx.W and MULx.L

Instructions which act only on registers, not on memory

Some arithmetic instructions cannot act directly on memory - the destination must be a register. This applies to:

ADDI, ADDX, ANDI, CMPI, ASL, ASR, LSL, LSR,

NEG, NEGX, NOT, EORI, ORI, SUBI, SUBX, Scc

Note that ADDQ and SUBQ can act directly on memory.

Restrictions on addressing modes for particular instructions

Even where a particular memory addressing mode does exist in ColdFire, some instructions are subject to further restrictions. Often, this is because of the limit of six bytes as the maximum length of a single instruction. Specific restrictions include:

Miscellaneous Omissions

There are a few miscellaneous omissions for specific instructions:

Instructions which behave differently from the 680x0 equivalent

In most cases, an instruction/addressing mode which does exist in ColdFire behaves exactly like its 680x0 equivalent, which makes it easy for experienced 680x0 programmers to understand ColdFire code. It also means that user-mode code written for ColdFire can generally run unchanged on a 680x0 processor, provided the new ColdFire-only instructions are not used.

However, there are a few subtle cases where the ColdFire instruction is not exactly the same as its 680x0 counterpart. The most important of these is that multiply instructions (MULU and MULS) do not set the overflow bit. This means that a 680x0 code sequence which checks for overflow on multiply may assemble and run under ColdFire, but give incorrect results.

ASL and ASR also differ in that they do not set the overflow bit - but this is less likely to cause problems for real programs!

Simplification of the supervisor programming model

Various members of the 68000 family have different register sets available at the supervisor level. The most important simplification in ColdFire's supervisor-level model is that there is only one stack pointer, shared for all code including interrupts, supervisor-level services, and user code. It follows from this that, on ColdFire, it is never safe to write below the stack, since any interrupt which occurs would overwrite the stored data. (Writing below the stack, though not recommended, is possible in some 680x0 systems in user mode, because interrupts cause a switch to the Interrupt or Supervisor Stack Pointer). A further issue is that ColdFire processors automatically align the stack to a four-byte boundary when an exception occurs, which can cause problems if code is reading or writing at a fixed offset from the stack pointer. In fact, it is strongly recommended (for performance reasons) that the ColdFire stack should be kept long-word aligned at all times.

New features in ColdFire Version 4 core

Version 4 of the ColdFire core architecture re-introduces some familiar 680x0 instructions, and also adds some new instructions. The main changes are:

Reintroduced:

New: