Science Fair Project Encyclopedia
The Motorola 68000 is a CISC microprocessor, the first member of a successful family of microprocessors from Motorola, which were all mostly software compatible. The entire series was often referred to as the m68k, or simply 68k.
Originally, the MC68000 was designed for use in household products (at least, that is what an internal memo from Motorola claimed). Later, it was used for the design of computers like the Apple Macintosh, Commodore Amiga and Atari ST and the original Sun Microsystems UNIX machines as well as the Apollo/Domain workstations. 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. In the Silicon Graphics's IRIS 1000 and 1200 terminals, the 68000 was also used.
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. The Dragonball low-voltage versions of the processor were used in the popular Palm series of PDAs from Palm Computing and Handspring's Visor, until the architecture was being phased out in favor of the ARM processor core. A small family of derivatives with integrated hi-speed serial ports (68302 and 68360) was used in many communication products from Cisco, 3com, Ascend, Marconi and others. The Motorola 68000 is also used in Texas Instruments' latest line of graphing calculators and in Dana's portable electronic typewriters.
Initial samples of the 68000 were released in 1979, and competed against the Intel 8086 and Intel 80286 with some success. By 1982 it was clocked at a then blisteringly-fast 8MHz, with the simplest instructions taking four clocks but the most complex ones requiring many more. However, the instructions did more than Intel processors. Motorola ceased production of the original NMOS 68000 in 2000, although derivatives continue in production, like 68HC000 (pin compatible, HCMOS version of 68000), the 680x0 family and the CPU32 family. As of 2001, Hitachi continued to manufacture the 68000 under license.
The 68000 was a clever compromise. When the 68000 was introduced, 16-bit buses 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.
It is important to note that even though the 68000 had a 16-bit ALU, addresses were always manipulated by 32-bit instructions. I.e. not only was the address space 32-bit, but flat addressing was used. Contrast this to the 8086, which had 20-bit address space, but could only access 16-bit (64 kilobyte) chunks without resorting to slow extra instructions. The clever 68000 compromise was that in spite of databus and ALU width being 16-bit, address arithmetic always is 32-bit (further, even for all dataregister ops there is a 32-bit version of the instruction). For the complex addressing mode, there is a fullsize address adder outside the ALU. E.g. a full 32-bit address register postincrement goes without speed penalty.
So even though starting out as "16-bit" cpu, the 68000 instruction set describes a 32-bit architecture. The importance of architecture cannot be emphasized enough. Throughout history, addressing pains have not been hardware implementation problems, but always architecture problems (instruction set problems, i.e. software compatibility problems). The successor 68020 with 32-bit ALU and 32-bit databus runs unchanged 68000 software at "32-bit speed", manipulating data up to 4 gigabytes, far beyond what software of other "16-bit" cpus (e.g. 8086) could do.
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 a 20-bit address (20-bit in the DIP/48-pin version and 22-bit in the PLCC/52-pin version, introduced later), and an 8-bit data bus. A planned future form (later the 68020) had a 32-bit data and address bus.
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.
Integer representation in the 68000 family is big-endian.
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, o"V"erflow, 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.
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.
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 - in other words, an NMI. Level 0 could be interrupted by any higher level. The level was stored in the status register, and was visible to user-level programs.
Hardware interrupts are signalled to the CPU using three inputs that encode the highest pending interrupt priority. A separate interrupt controller is usually required to encode the interrupts, though for systems that do not require more than three hardware interrupts it is possible to connect the interrupt signals directly to the encoded inputs at the cost of additional software complexity. The interrupt controller can be as simple as a 74LS148 priority encoder, or may be part of a VLSI peripheral chip such as the MC68901 Multi-Function Peripheral , which also provided a UART, timer, and parallel I/O.
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 through 15 were used to report various errors: bus error, address error, illegal instruction, zero division, CHK & CHK2 vector, privilege violation, and some reserved vectors that became line 1010 emulator, line 1111 emulator, and hardware breakpoint. Vector 24 started the real interrupts: spurious interrupt (no hardware acknowledgement), and level 1 through level 7 autovectors, then the 15 TRAP vectors, then some more reserved vectors, then the user defined vectors.
Since at a minimum the starting code address vector must always be valid on reset, systems commonly included some nonvolatile memory (e.g. ROM) starting at address zero to contain the vectors and bootstrap code. However, for a general purpose system it is desirable for the operating system to be able to change the vectors at runtime. This was often accomplished by either pointing the vectors in ROM to a jump table in RAM, or through use of bank-switching to allow the ROM to be replaced by RAM at runtime.
The 68000 did not meet the Popek and Goldberg virtualization requirements for full processor virtualization because it had a single unprivileged instruction "MOVE from SR", which allowed user-mode software read-only access to a small amount of privileged state.
The 68000 was also unable to easily support virtual memory, which requires the ability to trap and recover from a failed memory access. The 68000 does provide a bus error exception which can be used to trap, but it does not save enough processor state to resume the faulted instruction once the operating system has handled the exception. 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.
These problems were fixed in the next major revision of the 68K architecture, with the release of the MC68010. The Bus Error and Address Error instructions pushed a large amount of internal state onto the supervisor stack in order to facility recovery, and the MOVE from SR instruction was made privileged. A new unprivileged "MOVE from CCR" instruction was provided for use in its place by user mode software; an operating system could trap and emulate user-mode MOVE from SR instructions if desired.
Instruction set details
The standard addressing modes are:
- Register direct
- data register, e.g. "D0"
- address register, e.g. "A6"
- 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.
- Register indirect with an Index
- 8-bit signed offset, e.g. 8(A0, D0) or 8(A0, A1)
- PC (program counter) relative with displacement
- 16-bit signed offset, e.g. 16(PC). This mode was very useful.
- 8-bit signed offset with index, e.g. 8(PC, D2)
- Absolute memory location
- Either a number, e.g. "$4000", or a symbolic name translated by the assembler
- Most 68000 assemblers used the "$" symbol for hexadecimal, instead of "0x".
- Immediate mode
- Stored in the instruction, e.g. "#400".
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)
- Binary Coded Decimal Arithmetic: ABCD, and SBCD
- Logic: EOR (exclusive or), AND, NOT (logical not)
- 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
- Bit manipulation in memory: BSET (to 1), BCLR (to 0), and BTST (set the Zero bit)
- 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)
- Branch: Bcc (a branch where the "cc" specified one of 16 tests of the condition codes in the status register: equal, greater than, less-than, carry, and most combinations and logical inversions, available from the status register).
- Decrement-and-branch: DBcc (where "cc" was as for the branch instructions) which decremented a D-register and branched to a destination provided the condition was still true and the register had not been decremented to -1. This use of -1 instead of 0 as the terminating value allowed the easy coding of loops which had to do nothing if the count was 0 to begin with, without the need for an additional check before entering the loop.
The contents of this article is licensed from www.wikipedia.org under the GNU Free Documentation License. Click here to see the transparent copy and copyright details