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''. Its name was derived from the 68,000 transistors on the chip. == History == 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 International Amiga, Atari Atari ST, and the original Sun Microsystems Unix machines as well as the Apollo/Domain workstations. It was also used in the Sega Genesis/Sega MegaDrive, NeoGeo and several arcade machines, including Atari's classic Marble Madness, 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 ICs. 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 programming language code. The 68000 eventually saw its greatest success as a controller. Thousands of Hewlett-Packard, Printronix and Adobe Systems computer printers used it. Its derivative microcontroller, the Motorola CPU32 and Motorola 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 Pilot series of PDAs from Palm Computing and the Handspring Visor, until the architecture was gradually phased out in favor of the ARM architecture 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, such as the 68HC000 (a pin compatible, HCMOS version of 68000), the 680x0 family and the CPU32 family. As of 2001, Hitachi (company) continued to manufacture the 68000 under license. == 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. It is important to note that even though the 68000 had a 16-bit ALU, addresses were always stored as 32-bit quantities, i.e. it had a flat 32-bit address space. 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 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 modes, there is a fullsize address adder outside the ALU. For example, 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 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. 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 (as used in the Sinclair QL), 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. === Internal registers === The Central processing unit had 8 general-purpose data processor register (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 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 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 Endianness. === 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 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 Addressing mode, and almost all address modes were available for almost all instructions. Many programmers disliked the "near" orthogonal, 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 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. 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 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 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 Non-Maskable interrupt. 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 7400 series, 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. Read-only memory) 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 Random Access Memory, 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 semaphore (programming)s 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. ==See also== * 68k * x86 ==External links== *[http://68k.hax.com/ Descriptions of assembler instructions] *[http://www.cpu-collection.de/?tn=1&l0=cl&l1=68000 68000 images and descriptions at cpu-collection.de] 68k microprocessors Microprocessors
(:VAX, :320xx microprocessor usually produced more compact code than 68000 also. Sometimes the 8086 as well.
---
Hard to believe. The VAX is a 32-bit machine. (Yes, but it was byte-coded, very compact. GJ) The TI 32000 series is a RISC machine, isn't it? (possibly, for some definitions of RISC. But i meant the Natsemi chip 32016 and successors. I have now fixed the link! GJ) RISCs execute fast, but their code is not compact. (RISC is not usually compact. But several are not much worse than 68K, and the HP-PA allegedly beats nearly everything for code size. No i don't know how, and i never got my hands on one to test. GJ) Even space-optimized RISCs like the ARM need larger code than the 68K. They had to really sweat the ARM down with the "thumb" and "thumbscrew" approaches to reduce it to less than the 68K. Just reading about it tells me somebody had a bad 6 months getting there. Certainly the 8086 is not smaller; You'll cram about 2x as much code into a 68K machine per byte as an x86. If you don't believe -me-, see the 6/27/97 entry: http://vis-www.cs.umass.edu/~heller/cgi-bin/heller.cgi/?Frame=Main x86 code is just not that compact. User:Ray Van De Walker (It was 20% smaller than 68K the only time i actually coded something in both and cared enough to check the sizes. It did depend on what you were coding. 32 bit arithmetic on 8086 was horrible, and running out of registers was nearly as bad. And if you could make use of auto increment and decrement on 68K that was a big win. But the stuff i did mostly avoided all that, and was extremely compact on 8086. This experience was apparently almost normal for hand coded 16 bit stuff. 68K usually won for stuff from compilers. With the 80386, Intel became more "normal" and all the comparisons probably changed. -- Geronimo Jones) That web page (~heller) seems like an especially bogus comparison. 1) using C++ is a joke, neither CPU architecture was designed to support it. C would be a better language to compiler. 2) using different breed compilers is silly, you should use compilers from the same stable. For example, the lattice C compiler targets both architectures, as does Metrowerks (just about), and of course gcc. 3) the program you compile probably makes a big difference. As GJ points out 32-bit ops on an 8086 are a pain, but if your C program uses mostly 'int' then that's not a problem. On a 80486 it might not make much difference. --User:drj --- These are all reasonable objections. However, there's no doubt that many designers thought that it was more compact. So, I rewrote it from a NPOV to say so. I also rewrote the orthogonality discussion from a NPOV. I hope that helps. User:Ray Van De Walker --- A common misunderstanding among assembly-language programmers had to do with the DBcc loop instructions. These would unconditionally decrement the count register, and then take the branch unless the count register had been set to -1 (instead of 0, as on most other machines). I have seen many examples of code sequences which subtracted 1 from the loop counter before entering the loop, as a "workaround" for this feature. In fact, the loop instructions were designed this way to allow for skipping the loop altogether if the count was initially zero, ''without the need for a separate check before entering the loop''. The following simple code sequence for clearing bytes beginning at illustrates the basic technique for using a loop instruction:
move.l, a0
move.w , d0
bra.s @7
@1: clr.b (a0)+
@7: dbra d0, @1
Notice how you enter the loop by branching directly to the decrement instruction. This makes it execute the loop body precisely times, simply falling right out if is initially zero.
Also, even though the DBcc instructions only support a 16-bit count, it is possible to use them with a full 32-bit count as follows:
move.l , a0
move.l , d0
bra.s @7
@1: swap d0
@2: clr.b (a0)+
@7: dbra d0, @2
swap d0
dbra d0, @1
This does involve a bit more code, but because the inner loop executes up to 65536 times for each time round the outer loop, the extra time taken is insignificant.User:Ldo 10:05, 12 Sep 2003 (UTC)
== all motorola 68k ==
its nice and it needs improvement
== virtualization ==
The main page claimed that "the 68000 could not easily run a virtual image of itself without simulating a large number of instructions.". This is false; the only 68000 instruction which violates the Popek_and_Goldberg_virtualization_requirements is the "MOVE from SR" instruction. The 68010 made "MOVE from SR" privileged for that reason, and added an unprivileged "MOVE from CCR" instruction that could be used in its place.
It was further claimed that "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.". The i386 is MUCH harder to virtualize than a 68000, as it has very many violations of the Popek and Goldberg requirements, and they are much more difficult to deal with than the 68000's "MOVE from SR" instruction. See X86 virtualization, and in particular Mr. Lawton's paper referenced there.
I'm not sure how common the i386 was in avionics, but the 68000 and later 68K family parts were in fact widely used.
--User:Brouhaha 22:52, 23 Nov 2004 (UTC)
== "Its name was derived from the 68,000 transistors on the chip." ==
Please supply a reference for this. User:Mirror Vax 21:12, 18 Jun 2005 (UTC)
See other meanings of words starting from letter:
Words begining with Motorola_68000:
Motorola_68000
Motorola_68000
Motorola_68000_family
Motorola 68000
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''. Its name was derived from the 68,000 transistors on the chip. == History == 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 International Amiga, Atari Atari ST, and the original Sun Microsystems Unix machines as well as the Apollo/Domain workstations. It was also used in the Sega Genesis/Sega MegaDrive, NeoGeo and several arcade machines, including Atari's classic Marble Madness, 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 ICs. 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 programming language code. The 68000 eventually saw its greatest success as a controller. Thousands of Hewlett-Packard, Printronix and Adobe Systems computer printers used it. Its derivative microcontroller, the Motorola CPU32 and Motorola 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 Pilot series of PDAs from Palm Computing and the Handspring Visor, until the architecture was gradually phased out in favor of the ARM architecture 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, such as the 68HC000 (a pin compatible, HCMOS version of 68000), the 680x0 family and the CPU32 family. As of 2001, Hitachi (company) continued to manufacture the 68000 under license. == 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. It is important to note that even though the 68000 had a 16-bit ALU, addresses were always stored as 32-bit quantities, i.e. it had a flat 32-bit address space. 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 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 modes, there is a fullsize address adder outside the ALU. For example, 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 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. 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 (as used in the Sinclair QL), 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. === Internal registers === The Central processing unit had 8 general-purpose data processor register (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 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 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 Endianness. === 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 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 Addressing mode, and almost all address modes were available for almost all instructions. Many programmers disliked the "near" orthogonal, 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 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. 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 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 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 Non-Maskable interrupt. 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 7400 series, 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. Read-only memory) 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 Random Access Memory, 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 semaphore (programming)s 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. ==See also== * 68k * x86 ==External links== *[http://68k.hax.com/ Descriptions of assembler instructions] *[http://www.cpu-collection.de/?tn=1&l0=cl&l1=68000 68000 images and descriptions at cpu-collection.de] 68k microprocessors Microprocessors
Motorola 68000
(:VAX, :320xx microprocessor usually produced more compact code than 68000 also. Sometimes the 8086 as well.
---
Hard to believe. The VAX is a 32-bit machine. (Yes, but it was byte-coded, very compact. GJ) The TI 32000 series is a RISC machine, isn't it? (possibly, for some definitions of RISC. But i meant the Natsemi chip 32016 and successors. I have now fixed the link! GJ) RISCs execute fast, but their code is not compact. (RISC is not usually compact. But several are not much worse than 68K, and the HP-PA allegedly beats nearly everything for code size. No i don't know how, and i never got my hands on one to test. GJ) Even space-optimized RISCs like the ARM need larger code than the 68K. They had to really sweat the ARM down with the "thumb" and "thumbscrew" approaches to reduce it to less than the 68K. Just reading about it tells me somebody had a bad 6 months getting there. Certainly the 8086 is not smaller; You'll cram about 2x as much code into a 68K machine per byte as an x86. If you don't believe -me-, see the 6/27/97 entry: http://vis-www.cs.umass.edu/~heller/cgi-bin/heller.cgi/?Frame=Main x86 code is just not that compact. User:Ray Van De Walker (It was 20% smaller than 68K the only time i actually coded something in both and cared enough to check the sizes. It did depend on what you were coding. 32 bit arithmetic on 8086 was horrible, and running out of registers was nearly as bad. And if you could make use of auto increment and decrement on 68K that was a big win. But the stuff i did mostly avoided all that, and was extremely compact on 8086. This experience was apparently almost normal for hand coded 16 bit stuff. 68K usually won for stuff from compilers. With the 80386, Intel became more "normal" and all the comparisons probably changed. -- Geronimo Jones) That web page (~heller) seems like an especially bogus comparison. 1) using C++ is a joke, neither CPU architecture was designed to support it. C would be a better language to compiler. 2) using different breed compilers is silly, you should use compilers from the same stable. For example, the lattice C compiler targets both architectures, as does Metrowerks (just about), and of course gcc. 3) the program you compile probably makes a big difference. As GJ points out 32-bit ops on an 8086 are a pain, but if your C program uses mostly 'int' then that's not a problem. On a 80486 it might not make much difference. --User:drj --- These are all reasonable objections. However, there's no doubt that many designers thought that it was more compact. So, I rewrote it from a NPOV to say so. I also rewrote the orthogonality discussion from a NPOV. I hope that helps. User:Ray Van De Walker --- A common misunderstanding among assembly-language programmers had to do with the DBcc loop instructions. These would unconditionally decrement the count register, and then take the branch unless the count register had been set to -1 (instead of 0, as on most other machines). I have seen many examples of code sequences which subtracted 1 from the loop counter before entering the loop, as a "workaround" for this feature. In fact, the loop instructions were designed this way to allow for skipping the loop altogether if the count was initially zero, ''without the need for a separate check before entering the loop''. The following simple code sequence for clearing
move.l
See other meanings of words starting from letter:
M
MA | MB | MC | MD | ME | MF | MG | MH | MI | MJ | MK | ML | MN | MO | MP | MR | MS | MT | MU | MW | MX | MY | MZ |Words begining with Motorola_68000:
Motorola_68000
Motorola_68000
Motorola_68000_family
These materials are based on Wikipedia and licensed under the GNU FDL
YouTube.com videos better site than Turbo Tax 2007
