Inside Macintosh: PowerPC System Software /

Chapter 1 - Introduction to PowerPC System Software

The 68LC040 Emulator

The 68LC040 Emulator is the part of the PowerPC system software that allows 680x0 applications and other software to execute on PowerPC processor-based Macintosh computers. This emulator provides an execution environment that is virtually identical to the execution environment found on 680x0-based Macintosh computers. The emulator converts 680x0 instructions into PowerPC instructions, issues those instructions to the PowerPC microprocessor, and updates the emulated environment (such as the emulated 680x0 registers) in response to the operations of the PowerPC microprocessor.

In general, the 680x0 emulation environment supports all existing 680x0 applications that already work correctly on all Macintosh computers containing a Motorola 68020, 68030, or 68040 microprocessor. There are, however, some differences between the operation of the 68LC040 Emulator and an actual 68040 microprocessor. The following two sections provide some information on the general operation and limitations of the 68LC040 Emulator.

Note

Unless you are programming in assembly language or doing very low-level debugging, you're not likely to need the information in
the following two sections.

Emulator Operation

The 68LC040 Emulator implements the basic Motorola 68040 user mode instruction set. It does not, however, support any of the instructions from the optional 68881 or 68882 floating-point coprocessors. Moreover, although the emulator supports the operations of the Virtual Memory Manager, it does not support instructions from the 68851 Paged Memory Management Unit (PMMU). The 680x0-based Macintosh computer whose hardware configuration most closely resembles the software configuration of the 68LC040 Emulator is the Macintosh Centris 610, which contains the Motorola 68LC040 microprocessor. (The 68LC040 microprocessor is identical to the 68040 microprocessor except that it has no floating-point unit.) As a result, if your application or other software runs without problems on the Macintosh Centris 610, it is very likely to run without problems under the 68LC040 Emulator.

Note

For the complete specification of how you can expect both a
real 68040 and the 68LC040 Emulator to behave, see the
MC68040 32-Bit Microprocessor User's Manual.

The Gestalt function returns the value gestalt68020 when you pass it the selector gestaltProcessorType and the calling software is executing under the emulator. This return value is intended to highlight the two ways in which the 68LC040 Emulator more closely resembles a 68020 processor than a 68040 processor:

• The emulated environment does not support either the FPU or the MMU contained in an actual 68040 processor.
• The emulated environment creates exception stack frames in accordance with the 68020 exception frame model.

The 68LC040 Emulator consists of two main parts, a main dispatch table and a block of additional code called by entries in the main dispatch table. The main dispatch table contains two native PowerPC instructions for each recognized 680x0 operation code (or opcode). In cases where a 680x0 opcode can be handled by a single PowerPC instruction, the first native instruction in the dispatch table is enough to complete the requested operation. In most cases, however, the handling of a 680x0 opcode requires more than one PowerPC instruction. In that case, the first native instruction in the main dispatch table simply begins the emulation process.

The second native instruction in the emulator's main dispatch table is usually a PC-relative branch into the block of additional code. The additional code continues
the emulation of the 680x0 opcode begun by the first instruction.

The emulator's main dispatch table also includes entries that support private opcodes reserved for use by the system software, including both A-line and F-line instructions. For example, the Mixed Mode Manager communicates with the 68LC040 Emulator using A-line instructions embedded in routine descriptors. (See "Routine Descriptors" beginning on page 1-15 for details.) Other system software services, including the Virtual Memory Manager, also issue reserved opcodes to the emulator.

When the emulator is active, it maps all 680x0 registers to the registers on the PowerPC microprocessor, including the 680x0 program counter (PC) and Status Register (SR). The general-purpose register GPR1 serves as both the 680x0 and native stack pointer. The emulator also dedicates a native register to point to the 680x0 context block, a block
of data containing information that needs to be preserved across mode switches. The context block contains all the 680x0 registers, the addresses of the main dispatch table and the block of additional code, and other information used internally by the emulator. The emulator saves information into the context block when it is about to exit (for example, when a 680x0 application calls a piece of native code) and restores the information from the block when it is subsequently activated.

WARNING

You should not rely on any specific information about the 68LC040 Emulator's private data structures or opcodes.

Emulator Limitations

Largely because it is a purely software implementation of a hardware microprocessor, the 68LC040 Emulator sometimes exhibits behavior that differs from that of an actual 680x0 microprocessor. These operational differences can lead to problems, ranging from the obvious (for example, using the floating-point coprocessor instruction set, which is not supported by the 68LC040 Emulator) to the subtle (for example, depending upon a value in an undefined condition code bit). If your application or other software depends on 680x0 behavior that is not reproduced exactly by the 68LC040 Emulator, your product might have problems when executing under the emulator. The known exceptions to the documented 680x0 specifications concern

• coprocessors and instruction sets
• instruction timings
• deleted instructions
• unsupported instruction features
• instruction caches
• address error exceptions
• bus error exceptions
• memory-mapped I/O locations

The following sections describe these limitations in greater detail.

Coprocessors

As previously indicated, the 68LC040 Emulator does not support the instruction sets of either the 68881 or the 68882 floating-point coprocessor or of the 68851 PMMU. Any software that uses floating-point instructions is therefore not compatible with the 68LC040 Emulator. Because there are several 680x0-based Macintosh computers that
do not contain floating-point coprocessors, this restriction is not likely to cause new compatibility problems for your software. It's possible that you have used SANE to perform hardware-independent floating-point arithmetic. If so, you'll probably notice that floating-point calculations are performed even faster under the 68LC040 Emulator than on a real 680x0-based Macintosh computer. This is because PowerPC processor-
based Macintosh computers include an accelerated version of SANE written in native PowerPC code.

The 68LC040 Emulator does not support the 68851 PMMU instruction set (which also includes the 68030 and 68040 internal PMMUs). The Virtual Memory Manager is still supported, but using a different mechanism. Very few applications address the PMMU directly, so this restriction is not likely to affect many developers. Those applications that do address the PMMU directly are very likely already incompatible with A/UX and with the Virtual Memory Manager.

More generally, the 68LC040 Emulator does not support the coprocessor bus interface. As a result, the emulator does not support any externally connected hardware coprocessors.

Instruction Timings

The 68LC040 Emulator executes 680x0 instructions as fast as possible, making no attempt to maintain the same number of clock counts as on a real 68040 microprocessor. There are classes of instructions that execute in the same number of cycles whether
on a real 68040 or under the 68LC040 Emulator, but you should not depend on this.
In general, of course, your 680x0 application is most likely already independent of instruction timing, because it should run without problem on a wide range of 680x0 microprocessors having quite different clock rates.

Deleted Instructions

Several instructions included in the instruction set of the 68020 microprocessor were removed from the instruction sets of the 68030 and 68040 microprocessors. The deleted instructions are the CALLM and RTM instructions, which were intended for use in module calls. These instructions are not supported by the 68LC040 Emulator, and any attempt
to execute them will result in an illegal instruction exception. However, because these instructions are not present in any 680x0 microprocessor either before or after the 68020, this restriction is not likely to present compatibility problems for your software.

Unsupported Instruction Features

Several instruction or addressing mode fields and encodings are documented by Motorola as reserved. In addition, many instructions are documented as producing undefined condition code result bits or undefined register results. Accordingly, the behavior of these reserved fields and undefined results differs across the various members of the 680x0 family of microprocessors and under the 68LC040 Emulator. It is unlikely that any existing software intentionally depends on either reserved fields or undefined results. It is, however, remotely possible that through a programming error some software might be depending on these results and hence might behave differently under the emulator than on an actual 680x0.

Instruction Caches

The operation of the instruction cache in the 68040 microprocessor is not supported by the 68LC040 Emulator, although all of the bits in the Cache Control Register (CACR) and Cache Address Register (CAAR) related to the instruction cache are supported. In general, of course, your code should not address the cache registers directly.

Because both emulated code and data reside in the PowerPC data cache, the performance benefits associated with caching are still present. Indeed, the caching scheme used transparently by the 68LC040 Emulator results in a higher level of software compatibility than is found on actual 680x0 microprocessors. Some older versions of software that
are incompatible with the 68040 cache mechanism can run without problem under
the emulator.

Requests to invalidate the 68040 instruction cache are ignored by the 68LC040 Emulator. However, you should continue to issue those calls in order to remain compatible with 680x0-based Macintosh computers. Moreover, all cache flushing required for PowerPC code fragments is performed automatically by the Code Fragment Manager.

Note

For details on invalidating the 680x0 instruction cache, see the chapter "Memory Management Utilities" in Inside Macintosh: Memory.

It is possible, although unlikely, that an application depends on the ability of the 68040 instruction cache to retain a stale copy of instructions after the RAM copy of them has been changed. Such applications do not work correctly with 68000-based Macintosh computers (for example, the Macintosh Plus, SE, Classic\xAE, or PowerBook 100) and any 68040-based computers (for example, the Macintosh Quadra 950) when the Cache CDEV is used to disable caching. As a result, this nonemulated behavior should not present any new compatibility problems.

Address Error Exceptions

To improve the performance of branch instructions, the 68LC040 Emulator is not completely compatible with an actual 68040 microprocessor when detecting and reporting address error exceptions. A 680x0 microprocessor checks for address errors before completing the execution of a branch instruction; if it finds an address error, the microprocessor reports (in an address error exception frame that it creates on the stack) the PC at the beginning of the branch instruction. By contrast, the 68LC040 Emulator checks for address errors after executing a branch instruction; as a result, it reports the odd branch address as the PC in the exception frame. Because the PC of the instruction that caused the branch is not reported, you might find it more difficult to debug an application that commits address errors. You might also have compatibility problems if you install an address error exception handler.

Bus Error Exceptions

The 68LC040 Emulator handles bus error exceptions slightly differently than does a real 680x0 microprocessor. If you install a bus error handler, you might need to be aware of these differences. You also need to be aware of these differences when debugging your software, because most debuggers need to handle bus error exceptions.

The 68LC040 Emulator creates format $B exception frames when generating and handling bus errors. However, several fields within the exception frame are documented by Motorola as internal fields, and the contents of those fields are very likely to differ between the 68LC040 Emulator exception stack frame and the exception stack frame created by a 680x0 microprocessor. You should not rely on these reserved fields. To avoid any possible confusion that the internal state information in the emulated exception frame is compatible with the internal state information created by the 680x0 micro-
processors, the exception frame created by the emulator intentionally uses a value in the Version Number field of the exception frame that is different from the value put there by any 680x0 microprocessor.

In addition, there are several documented fields of the bus error exception frame that have slightly different values in the emulator than on a 680x0-based Macintosh computer. As long as bus error exception handlers do not modify these fields, it is still possible to use the RTE instruction to continue execution of the instruction that caused the exception. In particular, the PC field of the exception frame might not point to the exact beginning of the instruction that generated the exception. Instead, it might point to some location near the beginning of that instruction. Also, the Stage B address field and the Stage B and Stage C instruction pipe fields might not contain valid information.

Finally, the Special Status Word (SSW) differs under the 68LC040 Emulator. The 68LC040 Emulator does not distinguish between instruction space and data space accesses; instead, it converts instruction fetches to data space reads. As a result, the FC2-FC0 field always indicates either a supervisor or a user data space reference. In addition, the emulator never sets the FC, FB, or RM bits, and it ignores the RC and RB bits. The DF bit is fully supported, however, allowing both program completion of bus cycles and rerunning of bus cycles with the RTE instruction. The 68LC040 Emulator also puts valid values in the RM and SIZ bits.

Memory-Mapped I/O Locations

In general, most applications do not directly access memory-mapped I/O locations. Instead, they call device drivers or other system software routines to perform the requested I/O operations. For code (such as a device driver) that does directly access memory-mapped I/O locations, there are a number of compatibility issues. In some cases, the 680x0 emulation environment might not perform some write operations that a real 680x0 performs:

• The BSET and BCLR instructions might not write back an operand if none of the bits were changed as a result of the operation.
• Some memory-to-memory MOVE instructions might not write to memory if the source and destination addresses are the same.

You might need to modify your application to use different sequences of instructions to perform the operations if an I/O device was expecting these write bus cycles.

The TAS, CAS, and CAS2 instructions in the 68040 instruction set perform indivisible read, modify, and write memory operations. The 68040 bus architecture provides a special locked bus cycle for a read-and-write operation without allowing any other devices to request the bus between them. These indivisible bus cycles cannot be emulated. As a result, an alternate bus master type of I/O device might be allowed to modify a memory location between the read and the write operations.

The 68020 and 68030 bus interface supports a feature called dynamic bus sizing that allows 8- or 16-bit-wide I/O devices to work with the 32-bit-wide data bus. If the processor has a memory request for a data width that was larger than the data width of the device connected to the bus, the memory interface breaks the request into multiple requests that are the width of the device. For example, if a 32-bit read request is made to an 8-bit device, the memory interface actually performs four separate 8-bit reads to assemble the 32-bit data. This feature cannot be emulated. Any application or other software that depends upon this feature must to be modified to use separate instructions to access and assemble each piece of data.

The 68020 and 68030 bus interface also supports a feature called byte smearing that allows 8- or 16-bit data to be duplicated on a write operation across all 32 bits of the
data bus. The 68040 processor does not support this feature. This feature cannot be emulated, but solutions that were used for the 68040 should be compatible with the 68LC040 Emulator.

The 68020, 68030, and 68040 microprocessors define the NOP instruction as having the effect of synchronizing the pipeline and waiting for all prior bus operations to complete. The 68020 and 68030 have a very small pipeline, and bus operations normally finish
soon after they are issued. However, the 68040 and the PowerPC architecture let memory operations be queued and issued out of order. Because of this, the NOP instruction
might be needed to ensure that accesses to memory-mapped I/O devices occur in the proper order. The 68LC040 Emulator supports the features of the NOP instruction.
Any application that includes NOP instructions should be compatible with all Macintosh computers.

If an I/O device causes a bus timeout that results in a bus error exception, it might not
be possible for the PowerPC microprocessor--and therefore the 68LC040 Emulator--
to determine the memory address that was accessed. If all locations within a 4 KB
I/O page consistently time out, this problem might not occur, but if accesses to some locations within a page sometimes succeed, it is possible for this situation to occur.
A bus error exception is generated in that case, but the Data Fault Address field in
the exception frame will not be accurate and the DF bit in the SSW will not be set.