|
Motorola
68000
The Motorola 68000 is a CISC
microprocessor,
the first member of a successful family of microprocessors,
which were all mostly software compatible. The entire series was
often referred to as the m68k, or simply 68k
The
68000 family
People who are familiar with the PDP-11
or VAX
usually feel comfortable with the 68000. With the exception of
the split of general purpose registers into specialized data and
address registers, the 68000 architechture is in many ways a
32-bit PDP-11.
History
Originally, the MC68000 was designed for use in household
products (at least, that is what an internal memo from Motorola
claimed). Luckily it was used for the design of homecomputers
like the Amiga
and Atari.
It was also used in the Sega
Genesis/MegaDrive,
NeoGeo and several Arcade Machines as their main CPU. In the Sega
Saturn, the 68000 was used as the sound processor, and in
the Atari
Jaguar they were used as a main controller for all the other
dedicated hardware IC's.
Notable design wins include the Amiga,
the Apple
Macintosh, and the original Sun
Microsystems and SGI
UNIX
machines. 68000 derivatives persisted in the UNIX market for
many years, because the architecture so strongly resembles the
Digital PDP-11 and VAX, and is an excellent computer for running
C
code. The 68000 eventually saw its greatest success as a
controller. Thousands of HP,
Printronix
and Adobe
printers
used it.
Its derivative microcontrollers,
the CPU32 and Coldfire processors have been manufactured in the
millions as automotive engine controllers. It also sees use by
medical manufacturers and many printer manufacturers because of
its low cost, convenience, and good stability. As of 2001,
the Dragonball
versions of the processor are used in the popular Palm series of
PDAs from Palm
Computing and Handspring's Visor, though the architecture is
being phased out in favor of the ARM
processor core.
The Motorola 68000 is also used in Texas Instruments' latest
line of calculators. These four calculators (the TI-89,
TI-92,
TI-92
Plus, and Voyage
200 PLT) are the highest-end calculators. The TI-92 had a 10
MHz processor and 68KB RAM,
and was released in 1995. It was upgraded to the TI-92 Plus (in
1998) with 188KB RAM, 384KB Flash ROM, and the same 10 MHz processor.
Also released in that year was the TI-89, identical except it
was in a more traditionally shaped case.
Around 2000, the TI-92 Plus and the TI-89 were upgraded to
Hardware Version 2, and gaines a 12 MHz processor and a few
other hidden upgrades. In 2002, Texas Instruments relaeased its
latest über-calculator: the Voyage 200 PLT. This had the
Hardware Version 2 12MHz processor, 188 KB RAM, and a whopping
3.7 MB Flash ROM. It also had a clock and an Apps Desktop, both
of which were summarily released as Flash ROM updates for the
TI-92 Plus and TI-89.
Initial samples of the 68000 were released in 1982,
and competed against the Intel
8086 and Intel
80286 with some success. Initial clock rates were a
then-blisteringly fast 8MHz, with a rather slow eight to ten
clocks per instruction. However, the instructions did more than
Intel processors. Motorola ceased production of the 68000 in 2000,
although derivatives, notably the CPU32 family, continue in
production. As of 2001,
Hitachi
continued to manufacture the 68000 under license.
Architecture
Address
bus
The 68000 was a clever compromise. When the 68000 was
introduced, 16-bit busses were really the most practical size.
However, the 68000 was designed with 32-bit registers and
address spaces, on the assumption that hardware prices would
fall. To address the perceived markets, the actual 68000 was
designed in three forms. The base-form had a 24-bit address, and
a 16-bit data
bus. The short form, the 68008, had an 18-bit address
(possibly 19 or 20 bits, at least one firm addressed 512KBytes
with 68008s), and an 8-bit data bus. A planned future form
(later the 68020) had a 32-bit data and address bus.
Internal
registers
The
CPU
had 8 general-purpose data registers
(D0-D7), and 8 address registers (A0-A7). The last address
register was also the standard stack
pointer, and could be called either A7 or SP. This was a
good number of registers in many ways. It was small enough to
make the 68000 respond quickly to interrupts
(because only 15 or 16 had to be saved), and yet large enough to
make most calculations fast.
Having two types of registers was mildly annoying at times, but
really not hard to use in practice. Reportedly, it allowed the
CPU designers to achieve a higher degree of parallelism, by
using an auxiliary execution
unit for the address registers.
Status
register
The 68000 comparison, arithmetic and logic operations set bits
in a status register to record their results for use by later
conditional jumps. The bits were "Z"ero, "C"arry,
e"X"tend, and "N"egative. The eXtend bit
deserves special mention, because it was separated from the
Carry. This permitted the extra bit from arithmetic, logic and
shift operations to be separated from the carry for
flow-of-control and linkage.
The
instruction set
The designers attempted to make the assembly language
orthogonal. That is, instructions were divided into operations
and address modes. Almost all address modes were available for
almost all instructions. Many programmers disliked the
"near" orthogonality,
while others were grateful for the attempt.
At the bit level, the person writing the assembler
would clearly see that these "instructions" could
become any of several different op-codes. It was quite a good
compromise because it gave almost the same convenience as a
truly orthogonal machine, and yet also gave the CPU designers
freedom to fill in the op-code table.
The minimal instruction size was huge for its day at 16 bits.
Furthermore, many instructions and addressing modes added extra
words on the back for addresses, more address-mode bits, etc.
Many designers believed that the M68000 architecture had compact
code for its cost, especially when produced by compilers. This
belief in more compact code led to many of its design wins, and
much of its longevity as an architecture.
Most embedded system designers are acutely aware of the costs of
memory.
This belief (or feature, depending on the designer) continued to
make design wins for the instruction set (with updated CPUs) up
until the ARM
architecture introduced compressed Thumb op-codes that were
more compact.
Privilege
levels
The CPU, and later the whole family, implemented exactly two
levels of privilege. User mode gave access to everything except
the interrupt level control. Supervisor privilege gave access to
everything. An interrupt always became supervisory. The
supervisor bit was stored in the status register, and visible to
user programs.
A real advantage of this system was that the supervisor level
had a separate stack pointer. This permitted a multitasking
system to use very small stacks for tasks, because the designers
did not have to allocate the memory required to hold the stack
frames of a maximum stack-up of interrupts.
Interrupts
The CPU recognized 8 interrupt levels. Levels 0 through 7 were
strictly prioritized. That is, a higher-numbered interrupt could
always interrupt a lower-numbered interrupt. In the status
register, a privileged instruction allowed one to set the
current minimum interrupt level, blocking lower priority
interrupts. Level 7 was not maskable. Level 0 could be
interrupted by any higher level. The level was stored in the
status register, and was visible to user-level programs.
The "exception table" (interrupt vector addresses) was
fixed at addresses 0 through 1023, permitting 256 32-bit
vectors. The first vector was the starting stack address, and
the second was the starting code address. Vectors 3..15 were
used to report various errors: bus error, address error, illegal
instruction, zero division, CH1 & CHK2 vector, privilige
violation, and some reserved vectors that became line 1010
emulator, line 1111 emulator, and hardware breakpoint. Vector 24
started the real interrupts: spurious interrupt
(i.e. it wasn't properly hand-shaken), and level 1 .. level 7
autovectors, then the 15 TRAP vectors, then some more reserved
vectors, then the user defined vectors.
The interrupt controller was originally a separate IC, the
68901. This chip performed a rather complicated dance on the bus
to translate the seven pull-down interrupt lines into vectored
interrupts (level 1 through 7). The 68901 also provided a basic
UART and (if memory serves) a periodic interrupt timer. The
Motorola 68901 had a number of severe defects, including the
ability to lose the highest-priority interrupt if it and the
clock interrupt happened within some window of each other. The Mostek
part was superior.
The fixed exception table was screamingly annoying for hardware
designers.
One
wants a ROM
bootstrap,
but then once the OS
is up, one wants installable vectors.
A lot of effort went into circumventing the fixed vectors,
either through trampolines
(tables addressed to RAM)
in ROM
or through bank-switchable memory.
Another problem was the "privilege" logic. The
designers had clearly planned on having a minimal, but adequate,
two-tiered security system to support something like a UNIX
kernel.
This would limit the ability of user programs to access hardware
and interrupts. The design had security holes, which were fixed
in later processor models.
The 68000 was also unable to correctly return from an exception
on a failing memory access, a crucial feature to enable true virtual
memory. To simulate unlimited RAM, one wants to interrupt
when a memory access fails, and then the interrupt routine will
allocate a block of real RAM and read a piece of data on disk
into it. Several companies did succeed in making 68000 based
Unix workstations with virtual memory that worked, by using two
68000 chips running in parallel on different phased
clocks.
When the "leading" 68000 encountered a bad memory
access, extra hardware would interrupt the "main"
68000 to prevent it from also encountering the bad memory
access. This interrupt routine would handle the virtual memory
functions and restart the "leading" 68000 in the
correct state to continue properly synchronized operation when
the "main" 68000 returned from the interrupt.
Obviously this is an expensive, tricky, and very inconvenient
technique, and they upgraded to the 68010 as quickly as
possible.
A more subtle problem was that the 68000 could not easily run a
virtual image of itself without simulating a large number of
instructions. This problem persists in many modern versions of
the architecture, which is rarely used in these applications.
This lack caused the later versions of the Intel
80386 to win designs in avionic control, where software
reliability was achieved by executing software virtual machines.
In the next major revision, the 68010, most of these problems
were fixed.
Instruction
set details
The
standard address modes were:
-
Register
indirect
-
Simple
address, e.g. (A0)
-
Address
with post-increment, e.g. (A0)+
-
Address
with pre-decrement, e.g. -(A0)
-
Address
with a 16-bit signed offset, e.g. 16(A0)
-
Note
that the actual increment or decrement size was
dependent on the operand request: a byte read
instruction incremented the address register by 1, a
word read by 2, and a long read by 4.
-
Absolute
memory location
-
Either
a numer, e.g. "$4000", or a symbolic name
translated by the assembler
-
Most
68000 assemblers used the "$" symbol for hexadecimal,
instead of "0x".
Plus: access to the status register, and, in later models, other
special registers.
Most instructions had dot-letter suffixes, permitting operations
to occur on 8-bit bytes (".b"), 16-bit words
(".w"), and 32-bit longs (".l").
Most instructions are dyadic, that is, the
operation has a source, and a destination, and the destination
is changed. Notable instructions were:
-
Arithmetic:
ADD, SUB, MULU (unsigned multiply), MULS (signed multiply),
DIVU, DIVS, NEG (additive negation), and CMP (a sort of
subtract that set the status bits, but did not store the
result)
-
Shifting:
(logical, i.e. right shifts put zero in the most significant
bit) LSL, LSR, (arithmetic shifts, i.e. sign-extend the most
significant bit) ASR, ASL, (Rotates through eXtend and not:)
ROXL, ROXR, ROL, ROR
-
Multiprocessing
control: TAS, test-and-set,
performed an indivisible bus operation, permitting
semaphores to be used to synchronize several processors
sharing a single memory
-
Flow
of control: JMP (jump), JSR (jump to subroutine), BSR
(relative address jump to subroutine), RTS (return from
subroutine), RTE (return from exception, i.e. an interrupt),
TRAP (trigger a software exception similar to software
interrupt), (CHK a conditional software exception)
-
Decision:
Bcc (a branch where the "cc" specified one of 16
tests of the condition codes in the status register: equal,
greater than, less-than, cary, and most combinations and
logical inversions, available form the status register).
This
content from Wikipedia
is licensed under the GNU
Free Documentation License.
|
