The Motorola 68000 is a 32-bit CISC microprocessor core designed and marketed by Freescale Semiconductor (formerly Motorola Semiconductor Products Sector). As the first member of the successful m68k family of microprocessors, its software is generally forward compatible with the rest of the line. After twenty-seven years in production, the 68000 architecture, which economically combines several 16-bit datapaths, remains a popular choice for new designs.
History
The 68000 grew out of the MACSS (Motorola Advanced Computer System on Silicon) project, begun in 1976. One of the early decisions made was to develop a new "no compromise" architecture that paid little attention to backward compatibility. This was a gamble because it would mean adopters of the chip would have to learn the new system entirely from scratch. In the end, the only concession to backward compatibility was a hardware one: the 68k could interface to existing 6800 peripheral devices, but could not run 6800 code. However, the designers built in a tremendous amount of forward compatibility, which paid off once 68k expertise had been gained by end users. For instance, the CPU registers were 32-bits wide, though address and data buses outside the CPU were initially narrower. In contrast the Intel 8086/8088 were 16-bits wide internally. The MACSS team drew heavily on the influence of minicomputer processor design, such as the PDP-11 and VAX systems. The instruction set was developed with software development in mind more than hardware limitations; the idea was that developers familiar with these older systems would be comfortable programming the new microprocessor.
As the new design reached production a trade name had to be selected. The name "68000" was selected largely to provide some naming and marketing continuity with the earlier 6800, although there was little in common between the two designs. The name was justified by claiming the chip featured about 68,000 transistors, but in fact the count was closer to 70,000.
At the time, there was fierce competition among several of the then established manufacturers of 8-bit processors to bring out 16-bit designs. National Semiconductor had been first with its IMP-16 and PACE processors in 1973-1975, but these had issues with speed caused by their hole-doped MOS architecture. Texas Instruments was next, with its TMS9900, but its CPU was not widely accepted. Next came Intel with the Intel 8086/8088 in 1977/78. However, Motorola marketing stressed the (true) point that the 68000 was a much more complete 16-bit design than the others. This was reflected in its complexity. The transistor cell count, which was then a fairly direct measure of power in that era, was more than twice that of the 29,000 of the 8086.
The simplest 68000 instructions took four clock cycles, but the most complex ones required many more. An 8 MHz 68000 had an average performance of roughly 1 MIPS.
On average, the 68000's instructions in typical program code did more work per instruction than competing Intel processors, which meant that 68000 designs both needed less RAM to store machine code and were faster.[citation needed] Additionally, the 68000 offered a "flat" 24-bit addressing system supporting up to 16 MB of memory; at the time, this was a very large memory space. Intel chips instead used a segmented system which was much more difficult to program. Only in 1986 the 80386 allowed flat addressing. Thus the 68000 was easier to learn and work with, which led many engineers to prefer it to the Intel designs.
The original MC68000 was fabricated using an HMOS process with a 3.5-micron feature size. Initial engineering samples were released in late 1979. Production chips were available by 1980, with initial speed grades of 4, 6, and 8 MHz. 10 MHz chips became available during 1981, and 12.5 MHz chips during 1982. The 16.67 MHz "12F" version of the MC68000, the fastest version of the original HMOS chip, was not produced until the late 1980s.
To support low-cost systems with smaller memory sizes, Motorola introduced the MC68008 in 1982. This was a 68000 with an 8-bit data bus and a smaller (20 bits) address bus. The 68012 later brought a 32 bit address bus.
The 68HC000, the CMOS version of the 68000, was jointly introduced by Motorola and Hitachi in 1985.[1] Motorola's version was called the MC68HC000, while Hitachi's was the HD68HC000. The 68HC000 was eventually offered at speeds from 8 MHz to 20 MHz. Except for using CMOS circuitry, it behaved identically to the HMOS MC68000, but the change to CMOS greatly reduced its power consumption. The original HMOS MC68000 consumed around 1.35 watts at an ambient temperature of 25 °C, regardless of clock speed, while the MC68HC000 consumed only 0.13 watts at 8 MHz and 0.38 watts at 20 MHz. (Unlike CMOS circuits, HMOS circuits draw power whether they are switching or idle, so their power consumption varies little with clock rate, but it does vary with temperature.)
Motorola introduced the MC68HC001 in 1990.[2] This chip resembled the 68HC000 in most respects, but its data bus could operate in either 16-bit or 8-bit mode, depending on the value of an input pin at reset. Thus, like the 68008, it could be used in systems with cheaper 8-bit memories.
Several other companies were second-source manufacturers of the HMOS 68000. These included Hitachi (HD68000), Mostek (MK68000), Rockwell (R68000), Signetics (SCN68000), Thomson/SGS-Thomson (originally EF68000 and later TS68000), and Toshiba (TMP68000). Toshiba was also a second-source maker of the CMOS 68HC000 (TMP68HC000).
The 68000 became the foundation for a large number of microcontrollers and embedded processors. In 1989, Motorola introduced the MC68302 communications processor,[3] its first microcontroller to use a 68000 CPU core. This core was based on the CMOS 68HC000 but removed support for 8-bit 6800 peripherals. In 1991 Motorola introduced a separate processor chip based on this core, the MC68EC000.[4]
Motorola went on to make several additional microcontrollers with the 68EC000 core, including the MC68306 and MC68307 general-purpose microcontrollers, the MC68322 "Bandit" printer controller, the MC68356 modem data pump, and the MC68328 DragonBall, designed for portable devices. Other microcontrollers in the 683XX family used the more powerful CPU32 processor core.
Several of the 68EC000-based 683XX microcontrollers used a static version of the 68EC000 core; the processor clock of this core could be slowed or stopped to save power. In 1996 Motorola introduced this static core as a separate processor, the MC68SEC000.[5]
Motorola ceased production of the HMOS MC68000 and MC68008 in 1996,[6] but its spin-off company, Freescale Semiconductor, is still producing the MC68HC000, MC68HC001, MC68EC000, and MC68SEC000, as well as the MC68302 and MC68306 microcontrollers and later versions of the DragonBall family. The 68000's architectural descendants, the 680x0, CPU32, and Coldfire families, are also still in production.
Applications
The 68000 was first used during the early 1980s in high-priced systems, including multiuser microcomputers like the WICAT 150 [[1]], Tandy TRS-80 Model 16, and Fortune 32:16; single-user workstations such as Hewlett-Packard's HP 9000 Series 200 systems, the first Apollo/Domain systems, Sun Microsystems' Sun-1, and the Corvus Concept; and graphics terminals like Digital Equipment Corporation's VAXstation 100 and Silicon Graphics' IRIS 1000 and 1200. While Unix systems soon abandoned the original 68000 due to limitations of the processor, its derivatives remained popular in the Unix market throughout the 1980s.
During the mid 1980s, the 68000 was first used in personal and home computers, starting with the Apple Lisa and Macintosh, and followed by the Commodore Amiga, Atari ST, and Sharp X68000. The 68008, on the other hand, was only used in one home computer system, the Sinclair QL (though the QL was a sister machine to the ICL One Per Desk, which also used a 68008).
The 68000 eventually saw its greatest success as a controller. As early as 1981, laser printers such as the Imagen Imprint-10 were driven by external controllers using the 68000 as the CPU. The first HP LaserJet, introduced in 1984, used an 8 MHz 68000 in its built-in controller. Similar 68000-based integrated controllers were subsequently used in many other laser printers, including the Apple LaserWriter, the first PostScript laser printer, introduced in 1985. The 68000 continued to be widely used in laser printers throughout the rest of the 1980s, persisting well into the 1990s in low-end printers.
Outside traditional commercial or domestic computing applications, the 68000 also saw success in the field of industrial control systems. Among the systems which benefited from having a 68000 or derivative as their microprocessor were families of Programmable Logic Controllers (PLCs) manufactured by Allen-Bradley, Texas Instruments and subsequently, following the acquisition of that division of TI, by Siemens. Users of such systems do not accept product obsolescence at the same rate as domestic users and it is entirely likely that despite having been installed over 20 years ago, many 68000-based controllers will continue in reliable service well into the 21st century.
As technological advances obsoleted the 68000 from use in the standalone computing market, its use grew in consumer and embedded applications. Video game manufacturers used the 68000 as the backbone of many arcade games and home game consoles. Atari's Food Fight, from 1983, was one of the first 68000-based arcade games. The 68000 was the main CPU of many arcade systems during the late 1980s and early 1990s, such as Sega's System 16, Capcom's CPS-1 and CPS-2, and SNK's Neo Geo. A number of arcade systems used two 68000s; some even used three. During the 1990s, as arcade systems switched to more powerful processors for the main CPU, they often continued to use the 68000 as a sound controller.
The 68000 was also the central processor in several home game consoles of the late 1980s/early 1990s, including the Sega Mega Drive (Sega Genesis), the Sega Mega-CD (Sega CD), and the console version of the Neo Geo. Some later game consoles still included the 68000: the Sega Saturn used it as a dedicated sound controller, and in the Atari Jaguar it co-ordinated the activities of the other specialized graphics and sound chips.
The 68000-based 683XX microcontrollers have been utilized in a wide variety of applications, including networking and telephone equipment, television set-top boxes, and laboratory and medical instruments, among others. The MC68302 and its derivatives have been used in many communication products from Cisco, 3com, Ascend, Marconi and others. The DragonBall family was used in Palm Computing's popular Palm PDAs and in the Handspring Visor series, until Palm gradually phased out the architecture in favor of ARM processors. AlphaSmart uses the DragonBall family in later versions of its portable word processors.
Texas Instruments uses the 68000 in its high-end graphing calculators, the TI-89 and TI-92 series and Voyage 200. Early versions of these used a specialized microcontroller with a static 68EC000 core; later versions use a standard MC68SEC000 processor.
Architecture
Address bus
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.
Even though the 68000 had 16-bit ALUs, addresses were always stored as 32-bit quantities, i.e. it had a flat 32-bit address space. This meant that the 68000 was, and is, a 32-bit microprocessor. Contrast this to the 8086, which had 20-bit address space, but could only access 16-bit (64 kilobyte) chunks without manipulating segment registers. The 68000 achieved this functionality using three 16-bit ALUs. In normal operation, two 16-bit ALUs are chained together to perform an address operation, while the third executes the 16-bit arithmetic. For example, a 32-bit address register postincrement on a 16-bit ADD.W (An)+,Dn runs without speed penalty.
The original 68000 was internally a 16-bit part, but it was executing and existing within the parameters of a 32-bit ISA, as its 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 architectural 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 (for example, the 8086) could do. Contrast this with the problems posed by segmented architectures such as the 80286 which eventually had to be emulated entirely in software. It is seen as an act of great foresight for the 68000 series to have been 32-bit from the beginning.
However, forwards-incompatible software sometimes resulted from programmers storing data in the address bits (24 through 31) that weren't implemented on the bus. When such code was executed on a machine with a wider address bus, bus errors resulted. Software upgrades were required before Macintosh computers could use over 8 MB RAM. This software usually remained backwards compatible. Many applications were written with more foresight, and never had such problems.
The 68000 required word and longword data items to be aligned to an even byte boundary. An attempt to access them at an odd address caused an exception. This restriction was lifted in the 32-bit 68020, although a performance penalty was still inflicted.
Internal registers
The CPU had eight 32-bit general-purpose data registers (D0-D7), and eight 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 allow the 68000 to 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 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.
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, o"V"erflow, e"X"tend, and "N"egative. The e"X"tend 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, and 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.
With only 56 instructions 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 MC68000 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.
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 the Thumb instruction set that was similarly 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 7 interrupt levels. Levels 1 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 1 could be interrupted by any higher level. Level 0 means no interrupt. 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 exceptions pushed a large amount of internal state onto the supervisor stack in order to facilitate 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.
Article is taken from Wikipedia, the free encyclopedia
For direct link --> Click
No comments:
Post a Comment